Healthcare fulfillment methods and systems

ABSTRACT

Systems for filling and managing a patient&#39;s healthcare needs are provided. Some systems and methods described herein relate to a total healthcare fulfillment system. The healthcare fulfillment system of various embodiments is a central portal which coordinates with multiple parties, for example, with physicians, retail pharmacies, mail-order pharmacies, specialty providers, and patients in order to address all of a patient&#39;s prescription drug needs or other healthcare needs.

CROSS-REFERENCE TO RELATED PATENT APPLICATIONS

This application claims the benefit of U.S. Provisional Application61/786,076, filed Mar. 14, 2013, and entitled HEALTHCARE NEEDSFULFILLMENT SYSTEM, which is herein incorporated by reference in itsentirety.

BACKGROUND

1. Technical Field

The present technology relates to systems for filling and managing apatient's medical prescriptions and/or other healthcare needs.

2. Description of Related Art

Many healthcare recipients (“consumers”) have their purchases ofpersonal prescription medications paid for, in part, by payments topharmacies through prescription benefit plans (“plans”). These plans aregenerally offered to consumers through health maintenance organizations,employer groups, and government entities (“payers”). Under such plans, aconsumer receives a prescription for a medication from his or herphysician and submits it to a pharmacy to be filled. The pharmacy checksto see that the consumer is a member of a plan with which the pharmacyhas a contract and that the medication and dosage prescribed are withinthe approved scope of the plan contract. Upon verification of theserequirements, the pharmacy dispenses the medication to the consumer. Theconsumer pays the pharmacy a copayment amount (“copay”), which is lessthan the normal cost of the medication. The pharmacy must request, andwait to receive, the balance of the payment for the medication and itsdispensing services from a prescription benefit manager (“PBM”) withwhom the payer has contracted to manage the plan. The PBM invoices thepayer (i.e., the PBM's customer) for the consumer's transaction, alongwith a charge for its contracted fee. From the funds paid by the payer,the PBM pays the pharmacy's balance due. In such a system, payerstypically turn to PBMs to manage costs. Because the cost of medicationsis so high and is such a large component of medical care costsgenerally, there is an on-going effort on the part of PBMs and payers toseek ways to control medication costs. As all healthcare costs continueto rise, there is also an ongoing need for more controlled costmanagement of consumers' other healthcare needs.

SUMMARY

The systems and methods described herein each have several aspects, nosingle one of which is solely responsible for its desirable attributes.Without limiting the scope of this disclosure as expressed by the claimsthat follow, the more prominent features will now be discussed briefly.After considering this discussion, and particularly after reading thesection entitled “Detailed Description,” one will understand how thesample features described herein provide for a more comprehensive systemhaving several advantages over current prescription drug fulfillmentsystems.

The systems and methods described herein relate to a total healthcareneeds fulfillment system. The healthcare needs fulfillment system ofvarious embodiments is a computer-based central portal which facilitatescoordination between multiple parties, such as physicians, supplierssuch as pharmacies and specialty providers, and patients, in order toprovide some of or all the medical goods and services needed by apatient. In various embodiments, the computer-based healthcare needsfulfillment system is owned, managed, and/or operated by a prescriptionbenefits manager (PBM) and a patient's prescription-related interactionscenter around the PBM and the PBM's system. In certain embodiments, thesystem largely eliminates the need for a patient to communicate with afulfilling supplier such as a pharmacy. Such a system creates newopportunities for distributing prescriptions to suppliers forfulfillment and new opportunities for delivering prescriptions andhealth-related content to patients.

In some embodiments, the healthcare needs fulfillment system includes aweb-based or mobile interface through which patients can monitor andmanage their healthcare needs. The interface of some embodimentsdisplays all of a patient's prescribed medical goods and services acrosssuppliers—even if several suppliers are providing the various goods andservices. In some such embodiments, a patient can, within the userinterface, track the status of each prescribed good and service, monitoradherence to treatment plans across suppliers, and provide financialinformation to facilitate automatic payment to various suppliers.

In certain embodiments, the healthcare needs fulfillment system alsoprovides content, downloadable applications, and/or web-based interfacesdesigned to push healthcare management downstream to patients andempower patients. For example, the healthcare needs fulfillment systemof some embodiments generates and provides alerts to a patient ifpotential drug interactions are identified or if relevant health andwellness tips, reminders, and/or tools become available. The system ofsome embodiments provides a patient with personalized, curated contentrelated to health topics determined to be of relevance to the patientbased on the patient's prescribed goods and services, documented healthconditions, historical usage of the system, self-identified preferences,etc.

One aspect of the disclosure is directed to a method for fulfilling andmanaging prescriptions. In some embodiments, the method is implementedby a specialized PBM computer, such as a computer that is owned,managed, and/or controlled by a PBM (or other manager of health plans,programs, and/or prescriptions); such a computer is programmed toconcurrently manage prescriptions for a multitude of patients. Incertain embodiments, the method includes: electronically receiving aplurality of prescriptions for a patient from one or more users'computers, wherein each of the plurality of prescriptions identifies thepatient and a prescribed treatment; selecting supplier selectioncriteria to apply to the plurality of prescriptions; applying thesupplier selection criteria to automatically select one or morefulfilling suppliers from a set of certified suppliers, wherein each ofthe fulfilling suppliers is selected to fill one or more of theplurality of prescriptions; transmitting the plurality of prescriptionsto the respective fulfilling suppliers for fulfillment; receiving statusupdates from each of the fulfilling suppliers, wherein the statusupdates comprise prescription receipt confirmation, fulfillmentconfirmation, and shipment confirmation; and transmitting the statusupdates to a patient's computer in a format through which the statusupdates from all the fulfilling suppliers are together viewable by thepatient within a single user interface.

In some embodiments, the method also includes adjudicating andauthorizing fulfillment of each of the plurality of prescriptions. Incertain embodiments, adjudicating and authorizing fulfillment occursprior to transmitting the plurality of prescriptions to the respectivefulfilling suppliers for fulfillment. Additionally or alternatively, insome embodiments, the method includes: calculating a copayment priceowed by the patient for each of the plurality of prescriptions;accessing account information for a financial account of the patientfrom a database; deducting the copayment price from the financialaccount; and transmitting a payment to each of the fulfilling suppliers.In some embodiments, one payment is transmitted to each fulfillingsupplier, the payment including the copayment price owed by the patientand the price owed by the plan payer.

In some embodiments, the method additionally or alternatively includes:identifying the patient from each of the plurality of prescriptions;searching a database to identify a plan to which the patient belongs;and searching a database to identify the supplier selection criteriaassociated with the plan. In some such embodiments, selecting supplierselection criteria to apply to the plurality of prescriptions involvesselecting the identified supplier selection criteria associated with theplan to which the patient belongs.

In certain embodiments, the supplier selection criteria includes a setof rules dictating how the set of certified suppliers are to beevaluated to select the plurality of suppliers. In some suchembodiments, applying the supplier selection criteria includesevaluating the set of certified suppliers and selecting the fulfillingsuppliers based on total price of adjudication. For example, in someembodiments, for each of the plurality of prescriptions, the certifiedsupplier offering the lowest total price is selected. The lowest totalprice of adjudication may be determined, for example, from a list ofprices submitted by the suppliers and/or through a competitive biddingprocess. In some embodiments, total price includes the price of theprescribed healthcare good or service and any associated fulfillmentfees or other service fees charged by the supplier. In some embodiments,the fulfilling suppliers are selected based on a combination of totalprice of adjudication, performance rating, and/or ancillary serviceofferings. In other embodiments, the fulfilling suppliers may beselected based on supplier preferences specified by the payer for aparticular plan.

In some embodiments of the method, the set of certified suppliers isformed of, and limited to, suppliers that have met a minimum level ofservice requirements and have integrated into a healthcare needsfulfillment system operated by the PBM or other prescription, program,or plan manager.

Another aspect of the disclosure is directed to a computing system forprescription fulfillment and management, the computing system formed of,at least, a processor, a receiver, and a transmitter configured tooperate together to perform a method of fulfilling and managingprescriptions. In some embodiments, the processor is configured suchthat the processor, receiver, and transmitter perform any of the methodembodiments described above.

In yet another aspect of the disclosure, the technology is directed to anon-transitory machine-readable storage medium embodying a set ofinstructions that, when executed by a processor, cause the processor toperform operations or methods, such as, for example, a method offulfilling and managing prescriptions. In some embodiments, theinstructions cause the processor to perform any of the methodembodiments described above.

An additional aspect of the disclosure is directed to a method ofselecting a supplier to fulfill future prescriptions via a biddingprocess. In some embodiments, the method includes transmitting anelectronic link to a set of certified suppliers, wherein the linkconnects the set of certified suppliers to a bidding site. The methodmay further include setting minimum requirements that each bid needs tomeet in order to be accepted. In some embodiments, the method alsoincludes receiving one or more bids submitted by one or more of thecertified suppliers, wherein each bid includes a price at which thesubmitting supplier would fill a prescription received for a healthcaregood or service during a next time period. The method may furtherinclude automatically selecting a winning bid for each healthcare goodor service, wherein: each new prescription for a healthcare good orservice received during the next time period is sent to the suppliersubmitting the winning bid for the respective healthcare good orservice, and the new prescription is filled by the respective supplieraccording to the terms set forth in the winning bid until the newprescription expires. In some embodiments, the winning bid is selectedbased at least in part on price. For example, in some embodiments, thelowest price bid is selected to be the winning bid. In some embodiments,the winning bid is additionally or alternatively selected based at leastin part on the quantity or quality of ancillary services offered bysubmitting suppliers; for example, in some embodiments, the winning bidis the bid that includes the greatest quantity or quality of ancillaryservices as compared among various submitting suppliers that submitted abid below a threshold price.

In some embodiments of the method, each bid submitted by a certifiedsupplier is viewable by the set of certified suppliers, and eachcertified supplier is permitted to submit a plurality of bids during aduration of the bidding process. In other embodiments, only a currenttop bid is viewable by the set of certified suppliers at any particulartime during the bidding process. In still other embodiments, a certifiedsupplier's bid is submitted confidentially and is not viewable by othercertified suppliers.

In some embodiments, a method for fulfilling and managing prescriptionsis provided, which is implemented by a specialized PBM or otherprescription management computer programmed to concurrently manageprescriptions for a multitude of patients. The method may includeelectronically receiving a prescription for a patient. In someembodiments, the method also includes conducting a bidding process,which is the same, substantially similar, or similar to the biddingprocess described above. The method may further include determining if,through the bidding process, a winning bid was received for a particularhealthcare good or service. No winning bid was received if no certifiedsupplier submitted an acceptable bid for the healthcare good or service.In some embodiments, when no winning bid has been received, the methodfor fulfilling the prescription further includes one of the following:transmitting the prescription to a selected certified supplier selectedto fill one or more additional prescriptions for the patient, whereinthe selected supplier submitted the winning bid or bids for the one ormore additional prescriptions; transmitting the prescription to acertified supplier identified as having an expertise in a healthcondition associated with the healthcare good or service; or bundling aplurality of goods or services without winning bids together to formbundled packages and providing an electronic link to the set ofcertified suppliers to bid on the bundled packages. In some embodimentswhere the goods and services are bundled, the prescription istransmitted to the supplier that submits a winning bid on the bundledpackage that includes the prescribed healthcare good or service.

Another aspect of the disclosure is directed to a computing system forselecting a supplier to fulfill future prescriptions via a biddingprocess, the computing system formed of, at least, a processor, areceiver, and a transmitter configured to operate together to perform amethod of selecting suppliers via a bidding process. In someembodiments, the processor is configured such that the processor,receiver, and transmitter perform an embodiment of the method describedabove.

In yet another aspect of the disclosure, the technology is directed to anon-transitory machine-readable storage medium embodying a set ofinstructions that, when executed by a processor, cause the processor toperform operations or methods, such as, for example, a method ofselecting a supplier to fulfill future prescriptions via a biddingprocess. In some embodiments, the instructions cause the processor toperform an embodiment of the method described above.

A further aspect of the disclosure is directed to a method of curatingelectronic health content relevant to a health state of a patient. Themethod of various embodiments is implemented by a specialized computerprogrammed to concurrently curate electronic health content for amultitude of patients. In some embodiments, the method includes:electronically receiving a prescription, which identifies a prescribedtreatment for a patient; identifying a health condition or a category ofhealth conditions the patient is likely to have based on the prescribedtreatment for the patient; identifying content recommended for patientshaving the health condition or the category of health conditions; anddelivering the content to the patient.

In some embodiments, delivering the content to the patient involvestransmitting an electronic link to the patient within a computer userinterface to electronically connect the patient to the content. In someembodiments, the content is a web-based or mobile application.Additionally or alternatively, in some embodiments, identifying thehealth condition or the category of health conditions the patient islikely to have includes searching a database to identify a productclassification or service classification to which the prescribedtreatment belongs; in such embodiments, treatments are grouped intoclassifications based on the types of conditions they are tailored totreat.

Another aspect of the disclosure is directed to a computing system forcurating electronic health content relevant to a health state of apatient. In various embodiments, the computing system is formed of, atleast, a processor, a receiver, and a transmitter configured to operatetogether to perform a method of curating electronic health contentrelevant to a health state of a patient. In some embodiments, theprocessor is configured such that the processor, receiver, andtransmitter perform an embodiment of the method described above.

In yet another aspect of the disclosure, the technology is directed to anon-transitory machine-readable storage medium embodying a set ofinstructions that, when executed by a processor, cause the processor toperform operations or methods, such as, for example, a method ofcurating electronic health content relevant to a health state of apatient. In some embodiments, the instructions cause the processor toperform an embodiment of the method described above.

Another aspect of the technology is directed to a computerizedhealthcare needs fulfillment system. In some embodiments, thecomputerized system is designed to receive a prescription script fromthe computer of a physician prescribing a medical good or service for apatient. In other embodiments, the prescription script is received fromthe computer of a patient or the computer of a supplier filling theprescription for a patient. The computerized system of some embodimentsperforms checks to ensure that the prescribed good or service isappropriate for the patient. In some embodiments, the computerizedhealthcare needs fulfillment system applies a set of heuristics toidentify one or more suggested suppliers for filling a patient'sprescription. A supplier may be identified by the system as a suggestedsupplier based on one or more criteria, for example, based on the pricecharged by the supplier for the prescribed good or service, theproximity of the supplier to the patient, the performance rating of thesupplier, the expertise of the supplier, and/or other ancillary servicesoffered by the supplier.

In some embodiments, the healthcare needs fulfillment system facilitatescommunication with the patient, such as, for example, throughcoordination with a call center or by transmitting an electronic messagedirectly to the patient, to notify the patient when a better supplier isavailable for providing the patient's prescribed good or service. Insome embodiments, the computerized system determines whether a bettersupplier exists by comparing the current fulfilling supplier to the oneor more suggested suppliers. In some embodiments, if the currentfulfilling supplier is not one of the suggested suppliers, then a bettersupplier exists. In some embodiments, when one or more better suppliersexist, the patient is provided the option of switching to one of the oneor more better suppliers. In other embodiments, the computerized systemidentifies only one suggested supplier and automatically selects saidsupplier to fill the prescription script for the patient. In variousembodiments, the computerized system authorizes the prescription script,transmits the prescription script to the computer of the selectedsupplier, and receives status updates from the selected supplier'scomputer.

Another aspect of the disclosure is directed to another method offulfilling and managing prescriptions. The method of some embodimentsincludes: receiving a prescription in electronic form, wherein theprescription includes a pharmaceutical drug name and a dosage; receivingpatient information in electronic form, wherein the patient informationincludes an identifier linking a patient to a prescription benefit planif applicable; accessing a database of drug pricing data comprisingcurrent drug prices at a plurality of participating pharmacies;determining a suggested pharmacy based at least in part on thepharmaceutical drug name, the dosage, the prescription benefit plan ifapplicable, and the current drug pricing data; and sending theelectronic prescription to a selected pharmacy for fulfillment.

In some embodiments of the method, the suggested pharmacy is alsodetermined based, at least in part, on the location of the plurality ofparticipating pharmacies. In some embodiments, the suggested pharmacy isautomatically chosen to be the selected pharmacy. In other embodiments,identifying a suggested pharmacy includes: identifying a plurality ofsuggested pharmacy options, providing a list of the suggested pharmacyoptions to the user in a selectable format, and receiving an input fromthe user indicating the selected pharmacy. In some embodiments, theplurality of suggested pharmacy options comprises a mail-order optionand one or more retail pharmacies. In some embodiments, the prescriptionand patient information is provided in electronic form by a user. Insome such embodiments, the user is the patient or healthcare provider ofthe patient. In other embodiments, the prescription and patientinformation are sent by a user in a non-electronic format, and are laterreceived by the system in electronic format upon uploading by anindividual or computer. In some embodiments, the identifier is apatient-specific identification code or username linking the patient toa patient-specific profile, which stores patient-specific information,including at least the patient's: prescription benefit plan, birthdate,name, address, and current prescriptions. The patient-specific profileof some embodiments stores financial account information for thepatient. In some such embodiments, the method further includes deductingpayment from the financial account information when the electronicprescription is received, adjudicated, or fulfilled by the selectedpharmacy.

In some embodiments, the method further includes tracking the electronicprescription and updating a prescription status that is viewable by theuser when the selected pharmacy receives the electronic prescription,when the selected pharmacy adjudicates the electronic prescription, andwhen the selected pharmacy fulfills the electronic prescription.

In some embodiments, the method further includes receiving a questionfrom the patient, identifying a category to which the question pertains,and directing the question to an appropriate resource. In suchembodiments, an order status question or a payment question is directedto the selected pharmacy, a benefits question is directed to thepatient's pharmacy benefits manager, and a health question is directedto a professional health services representative or healthcare provider.

In some embodiments of the method, the current drug prices are updatedperiodically to reflect pricing data received from a plurality ofparticipating pharmacies during a bidding process. In such embodiments,the bidding process includes: providing various pharmacies with accessto participate in bidding covering a next pricing cycle, and receivingbids for the next pricing cycle from a plurality of participatingpharmacies.

Another aspect of the disclosure includes a system for fulfilling andmanaging prescriptions. The system of various embodiments includes: areceiver configured to receive an electronic prescription and patientinformation from a user via a web-based interface, wherein theelectronic prescription comprises a pharmaceutical drug name and adosage, and the patient information comprises an identifier linking apatient to a prescription benefit plan if applicable; a database of drugpricing data comprising current drug prices at a plurality ofparticipating pharmacies; a processor configured to determine asuggested pharmacy based at least in part on the pharmaceutical drugname, the dosage, the prescription benefit plan, and the current drugpricing data; and a transmitter configured to send the electronicprescription via a web-based interface to a selected pharmacy forfulfillment.

In some embodiments, the system further includes a memory configured tostore a patient-specific profile, which comprises patient-specificinformation, including at least the patient's: prescription benefitplan, birthdate, name, address, and current prescriptions. In someembodiments, the system further includes a memory configured to storepharmacy-specific information, including at least a name and an addressfor each pharmacy. In some such embodiments, the memory comprises aweb-accessible database.

A further aspect of the disclosure is directed to a method of fulfillingand managing prescriptions. The method includes: receiving a processedclaim record from a payer, PBM, or claim aggregator, wherein theprocessed claim record identifies a fulfilling pharmacy, a prescriptiondrug, a patient, and an address of the patient; generating an eligibleclaim switch file; sending the eligible claim switch file to a pharmacyevaluator; receiving a report from the pharmacy evaluator identifying asuggested pharmacy, wherein the pharmacy evaluator identifies asuggested pharmacy by evaluating a plurality of pharmacies at least inpart on proximity to the patient and price of the prescription drug;determining if the patient is a target patient, wherein a patient is atarget patient if the fulfilling pharmacy is not the suggested pharmacy;and sending a list including the target patient to a caller forcontacting to determine if the target patient wants to transfer theprescription to the suggested pharmacy.

In some embodiments of the method, the suggested pharmacy includes aplurality of suggested pharmacy options. In some embodiments, the methodfurther includes calling the target patient to determine if the targetpatient would like to transfer the prescription to the suggestedpharmacy.

In some embodiments, the method further includes: receiving anotification from the caller when the target patient authorizes atransfer to a new pharmacy, and contacting the new pharmacy to transferthe prescription for the patient, wherein the new pharmacy is thesuggested pharmacy or one of the plurality of suggested pharmacyoptions. In some embodiments, the pharmacy evaluator is an outsidevendor or operated by an outside vendor. Additionally or alternatively,in some embodiments, the pharmacy evaluator is a server or computer. Insome embodiments, the caller is an outside vendor or operated by anoutside vendor. Additionally or alternatively, in some embodiments, thecaller is a person or computer.

Furthermore, an aspect of the disclosure is directed to a system forfulfilling and managing prescriptions in which the system includes: areceiver configured to receive a processed claim record from a payer,PBM, or claim aggregator via a web-based interface, wherein theprocessed claim record identifies a fulfilling pharmacy, a prescriptiondrug, a patient, and an address of the patient; a processor configuredto generate an eligible claim switch file; and a transmitter configuredto send the eligible claim switch file to a pharmacy evaluator. In someembodiments, the receiver is further configured to receive a report fromthe pharmacy evaluator identifying a suggested pharmacy, the processoris further configured to determine if the patient is a target patient(wherein a patient is a target patient if the fulfilling pharmacy is notthe suggested pharmacy), and the transmitter is further configured tosend a list including the target patient to a caller for contacting todetermine if the target patient wants to transfer the prescription tothe suggested pharmacy.

These are just some of the system's potential features and functions.Any particular system may have some of or all these features andfunctions and/or additional or alternative features and functions. Theforegoing is a summary and thus contains, by necessity, simplifications,generalization, and omissions of detail; consequently, those skilled inthe art will appreciate that the summary is illustrative only and is notintended to be in any way limiting. Other aspects, features, andadvantages of the systems, methods, devices, and/or processes describedherein will become apparent in the teachings that follow.

BRIEF DESCRIPTION OF THE DRAWINGS

The above-mentioned aspects, as well as other features, aspects, andadvantages of the present technology will now be described in connectionwith various embodiments, with reference to the accompanying drawings.The illustrated embodiments, however, are merely examples and are notintended to be limiting.

FIG. 1 is a schematic block diagram of one embodiment of a healthcareneeds fulfillment system, which depicts the system participants andinteractions between the participants.

FIG. 2 is a schematic block diagram of one embodiment of a healthcareneeds fulfillment system, which depicts the system participants andinteractions between the participants.

FIG. 3 is a functional block diagram of one embodiment of a healthcareneeds fulfillment system.

FIG. 4 is a flowchart illustrating one embodiment of a method forfulfilling and managing prescriptions performed by a healthcare needsfulfillment system.

FIG. 5 is a flowchart illustrating another embodiment of a method forfulfilling and managing prescriptions performed by a healthcare needsfulfillment system.

FIG. 6 is a flowchart illustrating another embodiment of a method forfulfilling and managing prescriptions performed by a healthcare needsfulfillment system.

FIG. 7 is a flowchart illustrating another embodiment of a method forfulfilling and managing prescriptions performed by a healthcare needsfulfillment system.

FIG. 8A is a flowchart illustrating an embodiment of a method foridentifying a supplier of a pharmaceutical drug, the method performed bya healthcare needs fulfillment system.

FIG. 8B is a flowchart illustrating another embodiment of a method foridentifying a supplier of a pharmaceutical drug, the method performed bya healthcare needs fulfillment system.

FIG. 9 is a flowchart illustrating an embodiment of a method foranswering patients' questions, the method performed by a healthcareneeds fulfillment system.

FIG. 10 is a flowchart illustrating an embodiment of a method forcurating and delivering content to a patient, the method performed by ahealthcare needs fulfillment system.

DETAILED DESCRIPTION OF CERTAIN EMBODIMENTS

In the following detailed description, reference is made to theaccompanying drawings, which form a part of the present disclosure. Theillustrative embodiments described in the detailed description,drawings, and claims are not meant to be limiting. Other embodiments maybe utilized, and other changes may be made, without departing from thespirit or scope of the subject matter presented here. It will be readilyunderstood that the aspects of the present disclosure, as generallydescribed herein, and illustrated in the Figures, can be arranged,substituted, combined, and designed in a wide variety of differentconfigurations, all of which are explicitly contemplated and form partof this disclosure. For example, a system or apparatus may beimplemented or a method may be practiced using any number of the aspectsset forth herein. In addition, such a system or apparatus may beimplemented or such a method may be practiced using other structure,functionality, or structure and functionality in addition to or otherthan one or more of the aspects set forth herein.

Similarly, methods disclosed herein may be performed by one or morecomputer processors configured to execute instructions retrieved from acomputer-readable storage medium. A computer-readable storage mediumstores information, such as data or instructions, for some interval oftime, such that the information can be read by a computer during thatinterval of time. Examples of computer-readable storage media arememory, such as random access memory (RAM), and storage, such as harddrives, optical discs, flash memory, floppy disks, magnetic tape, papertape, punch cards, and Zip drives.

Unless otherwise defined, each technical or scientific term used hereinhas the same meaning as commonly understood by one of ordinary skill inthe art to which this disclosure belongs. In accordance with the claimsthat follow and the disclosure provided herein, the following terms aredefined with the following meanings, unless explicitly stated otherwise.

As used herein, the term “comprising” or “comprises” is intended to meanthat the devices, systems, and methods include the recited elements, andmay additionally include any other elements. “Consisting essentially of”shall mean that the devices, systems, and methods include the recitedelements and exclude other elements of essential significance to thecombination for the stated purpose. Thus, a device or method consistingessentially of the elements as defined herein would not exclude othermaterials or steps that do not materially affect the basic and novelcharacteristic(s) of the claimed invention. “Consisting of” shall meanthat the devices, systems, and methods include the recited elements andexclude anything more than a trivial or inconsequential element or step.Embodiments defined by each of these transitional terms are within thescope of this disclosure.

As used herein, a “pharmacy” shall refer to any entity certified as alicensed pharmacy; such licensed pharmacies may include, for example,retail pharmacies, mail order pharmacies, wholesalers, Central Fillproviders, at the like.

As used herein, a “supplier” is an entity that supplies healthcare goodsand/or services to patients; the term may refer to, for example, apharmacy, a provider of biotherapeutics, other specialty therapies, orhealthcare services, or a provider of disposable or durable medicalgoods.

As used herein, “patient” refers to any individual who currentlyreceives or has previously received medical advice and/or treatment. Theterm shall include any individual who has visited a medical professionaland received a prescription for an acute or chronic treatment or medicaltest.

As used herein, a “prescription,” a “prescription script,” a “script,”and an “Rx” may refer to a written or electronic prescription orrecommendation from a healthcare provider for a healthcare good orservice.

As used herein, “healthcare goods” include, but are not limited to,pharmaceutical drugs, biologic therapeutics, dietary supplements,vitamins, over-the-counter medications, durable medical equipment,disposable medical supplies, and the like.

As used herein, “healthcare services” include, but are not limited to,laboratory testing, imaging, acupuncture, chiropractic services, and thelike.

As used herein, a “user” shall refer to any individual who interactswith, or otherwise uses, any of the systems disclosed herein. Forexample, a user may be a patient, a patient's guardian or caregiver, asupplier, a healthcare provider, or an employee or contractor of ahealthcare provider or healthcare facility.

As used herein, a “consumer” may refer to any individual who has used,consumed, and/or purchased healthcare goods or services. The term mayrefer to a patient or a patient's guardian or caregiver.

As used herein, a “portal” or “central portal” is an entryway to ahealthcare needs fulfillment system and may particularly refer to, forexample, a graphical user interface through which a user can access andinteract with content stored within the healthcare needs fulfillmentsystem. The term may refer to a web-based and/or mobile applicationdashboard that brings together information from a plurality of sources,organizing and displaying content relevant to a patient's healthcare andfacilitating communication between parties important to the patient'shealthcare.

For convenience of description and ease of understanding, the discussionand examples provided herein are often directed to systems and methodsfor fulfilling and managing pharmaceutical prescriptions. However, oneof skill in the art will understand that the content of the presentapplication applies equally to other healthcare needs, and all suchapplications are expressly contemplated and hereby form part of thisdisclosure. For example, each of the systems and methods describedherein may be used for fulfillment and management of orders for anyhealthcare good or service prescribed or recommended to a patient, suchas biologic therapeutics, supplements, vitamins, over-the-countermedications, durable medical goods, disposable medical supplies,laboratory testing, imaging, acupuncture, chiropractic services, and thelike.

INTRODUCTION

The systems and methods described herein relate to a total healthcareneeds fulfillment system. The healthcare needs fulfillment system ofvarious embodiments is formed of a computer or a network of computers,which provide a central portal to facilitate coordination with partiessuch as physicians, retail pharmacies, mail order pharmacies, specialtyproviders, and patients in order to address all of a patient'shealthcare needs, while minimizing the burden on the patient. Thehealthcare needs fulfillment system of various embodiments is designedto reduce healthcare costs and improve patient care and compliance. Insome embodiments, the healthcare needs fulfillment system isparticularly designed to reduce the cost of prescription drugs andimprove patient adherence to prescribed prescription drug regimens.

Medication usage is commonly differentiated between acute care usage,which is short term (30 days or less) administration to treat immediateillnesses or conditions, and maintenance usage, which is long term (morethan 30 days) treatment of chronic illnesses or conditions such ashypertension, high cholesterol levels, arthritis, neurology conditionsand the like. Maintenance medication dispensing and usage represents amajor healthcare cost (on the order of 75% of prescription costs formany plans), especially due to aging of the American population, andtherefore, control of maintenance prescription costs is a principalfunction of prescription benefit plans and the PBMs that manage them.Dispensing pharmacies are normally of two types: retail pharmacies(which are local neighborhood businesses where the patient appears inperson, can meet with a pharmacist, orders his/her medication, and canusually leave a few minutes later with the dispensed medication in hand)and mail order pharmacies (which are large facilities, usually not opento personal visits from individual patients, but from which a patient'smedication order received by mail or through the internet issubsequently filled and dispensed to the patient via mail or courierservice).

It is normally recognized by the industry that acute care prescriptionsare dispensed primarily by retail pharmacies, since the patientfrequently needs the medication immediately and cannot accept themultiday delay inherent in submitting and dispensing prescriptionmedications from the mail order pharmacies. On the other hand, PBMscommonly urge or even mandate that patients in the plans they administerobtain their maintenance medications from mail order pharmacies. It is awidely held belief that mail order pharmacies have lower operating costsand offer greater discounts available on medication coverage. To theextent that such is the case, use of mail order pharmacies may be adesirable cost control strategy. Moreover, there is some evidencesuggesting that mail order pharmacies promote better patient adherenceby commonly providing 90-day supplies and delivering directly to apatient's home (resulting in fewer gaps in a patient's ready access to aprescribed medication). Mail order pharmacies often also receive higherquality and safety ratings than retail pharmacies. However, manypatients experience anxiety and/or annoyance when they are forced to usea mail order pharmacy. Numerous studies have established that, for manyprescription consumers, direct contact with a pharmacist is veryimportant. Professional pharmacists are held in very high regard bypatients and their advice is eagerly sought. Most patients are notknowledgeable about medications and a prescribing physician's schedulemay not provide sufficient time for a patient to be able to get what heor she believes to be sufficient information from the prescribingphysician about all aspects of concern about a prescribed medication.Patients want to be able to speak directly to a skilled health careprofessional for more information about their medications, especiallywhen a long-term maintenance medication is involved. The prospects for apatient's successful implementation of a medication regimen are enhancedwhen the patient understands and is comfortable with the medicationprescribed. Accordingly, as mail order pharmacies become increasinglyutilized and mandated by plans, there is a need for an automated orsemi-automated system that can fill the advisory role of a pharmacist.There is utility in providing patients with a user-friendly web-basedportal, software application, and/or call center through which patientscan learn more about their health conditions and prescribed medications.

Additionally, physicians and other health care providers who writeprescriptions often have choices among the different medications theycan prescribe for a patient. A physician can, for instance, prescribe abrand name medication or a generic form of that medication, or thephysician can choose between two or more different but therapeuticallyequivalent medication compositions. There are significant differences inretail cost among the different medication forms, with generic formsnormally substantially lower in cost than brand name medications. Evenwithin each group (brand name or generic), there can be substantial costdifferences, depending usually on the wholesale prices set by thevarious manufacturers. Prices can also vary significantly betweenpharmacies.

It is, thus, extremely difficult for patients, and more generally,consumers, to compare prescription drug prices between pharmacies. It isalso extremely difficult for consumers to compare pharmacies accordingto other factors such as pharmacy expertise, performance ratings, and/orthe appropriateness of substitute or generic medications. As such, mostpatients are not properly qualified to make assessments about whichpharmacy is best for their particular prescription fulfillment.Consequently, needs go unmet and costs are not optimally controlled.Many patients today are unable to optimally select the best pharmacybased on their needs and prescription drug costs.

What would instead be desired is a total fulfillment system, such as anyone of the systems described herein. In some embodiments of a totalhealthcare needs fulfillment system, the pharmacy best suited to fulfilla prescription is the pharmacy that is actually selected to fulfill theprescription. In some embodiments, the system matches pharmacies to theprescription requests that they are best suited to fulfill. Thismatching may be accomplished in a manner that reduces costs. In someembodiments, the matching process does not rely solely uponpricing/costs to determine which pharmacy is best suited to fulfill eachprescription, but also considers factors such as location, planpreferences, pharmacy expertise, and/or pharmacy performance. In someembodiments, this system simplifies prescription ordering services andoperates with minimum burden on the patients using the system, whilestill providing patients with choice.

The system of some embodiments interfaces with both mail order andretail pharmacies; in other embodiments, the system interfacesexclusively with non-retail pharmacies. In some embodiments, the systemworks with dispensers of both brand name and generic medications, and assuch, is able to compare cost differences between equivalentmedications. For example, in some embodiments, the system may determineif prescription drug substitutions are appropriate, and if so, select apharmacy that supplies the lowest priced medication, be it generic orbrand name, when a physician writes a prescription for a brand namedrug. In some embodiments, the system coordinates a bidding process withpharmacies to determine which pharmacies supply the lowest pricedmedication and/or the best combination of affordable medication andancillary service offerings.

In some embodiments, the system provides a central portal for a patientto manage and view all of his/her prescriptions in one place, while thesystem may also divide and send the patient's prescriptions to differentpharmacies based on pharmacies' expertise and prices. Such a system mayresult in more optimal costs and services and permit pharmacies to moreefficiently manage their inventories.

The system of some embodiments also provides a central resource whichpatients and consumers can access to ask questions regardingprescription orders, copays, prescription benefits, and theirhealthcare, health conditions, and general health.

The total fulfillment system of some embodiments provides an onlinetracking system allowing patients, doctors, and other users of thesystem to track prescription orders. Such a system may allow users totrack when an order has been received by a pharmacy, adjudicated,fulfilled, and shipped. The data from such a system could ideally beused to track prescription ordering histories and to provide data thatcan be analyzed to determine how to increase prescription fulfillmentefficiencies.

System Overview

FIG. 1 is a schematic block diagram of one embodiment of a healthcareneeds fulfillment system 100. The diagram depicts the systemparticipants and interactions between the participants. The healthcareneeds fulfillment system 100 is operated by the healthcare hub 102. Thehealthcare hub 102 receives information from, and sends information to,doctors 104, retail pharmacies 106, mail order pharmacies 108, specialtyproviders 109, call centers 110, and patients 112. (As used herein,“doctor” may refer to a physician, nurse, physician's assistant, orother employee or contractor of a physician.) The patient 102 is alsoable to interact with each participant in the system, and in someembodiments, the patient 102 exchanges information with the patient'sdoctor 104, a call center 110, a retail pharmacy 106, a mail orderpharmacy 108, a specialty provider 109, and/or the healthcare hub 102.In a preferred embodiment, healthcare needs fulfillment system 100 is,at least in part, a network of communicatively-connected computers andall references to doctors 104, retail pharmacies 106, mail orderpharmacies 108, specialty providers 109, call centers 110, and patients112 refer, specifically, to computers operated by doctors, retailpharmacies, mail order pharmacies, specialty providers, call centers,and patients, respectively. In various embodiments, the healthcare hub102 is formed of one or more servers or other computers. The healthcarehub 102 of some embodiments is owned, managed, and/or operated by a PBMor other manager of health plans, programs, and/or prescriptions.

The healthcare hub 102 is configured to exchange information with thesystem participants in order to manage prescription fulfillment. Thehealthcare hub 102 of various embodiments is configured to achieve oneor more of the following objectives: reduce healthcare costs, minimizethe burden of prescription management experienced by the patient, ensurethat the patient receives the correct prescribed goods or services, andprovide an avenue for the patient to receive answers to health andhealthcare-related questions. In some embodiments, the healthcare hub102 achieves one or more of the following objectives through theexchange of information with the system participants. The healthcare hub102 receives information from a doctor 104 via a communication link 120.This information can include, for example, a prescription (script) for apatient 112 and information about the patient 112. The information aboutthe patient 112 can include, for example, a patient-specific identifierand/or information about a patient's health conditions, prescribeddrugs, medical history, height, weight, and/or birthdate. The healthcarehub 102 can transmit information back to the doctor 104 via thecommunication link 120. In some embodiments, the communication link 120is a two-way (forward and reverse) communication link. The healthcarehub 102 may, for example, request additional information from the doctor104. In some embodiments, the healthcare hub 102 requests clarificationabout whether a prescribed brand name drug can be substituted with acomparable generic drug. The healthcare hub 102 may also contact thedoctor 104, for example, to inquire about gaps in care, to communicatebest practices in care, to provide tips for managing a patient's diseasestate, or to alert the doctor 104 that the patient 112 is currentlyreceiving prescriptions that may negatively interact with a prescriptionnewly prescribed by the doctor 104. The communication link 120 of someembodiments includes an internet connection. In other embodiments, thecommunication link 120 may be a telephonic or facsimile connection.

In some embodiments, once the healthcare hub 102 has received aprescription from a doctor 104 and verified that it is an appropriateprescription, the healthcare hub 102 may transmit the prescription to aretail pharmacy 106, a mail order pharmacy 108, or a specialty provider109 via communication link 122, communication link 124, or communicationlink 125, respectively. In some embodiments, the communication links122, 124, and 125 are two-way (forward and reverse) communication links.The retail pharmacies 106, mail order pharmacies 108, and specialtyproviders 109 of some embodiments send notifications to the healthcarehub 102 via communication link 122 as a prescription is processedthrough the respective pharmacy's system. For example, in someembodiments, the retail pharmacy 106 will send notifications to thehealthcare hub 102 via the communication link 122 when the prescriptionorder has been received, processed, and filled. This may allow thehealthcare hub to generate prescription status updates. Similarly, insome embodiments, the mail order pharmacy 108 and specialty providerssend notifications to the healthcare hub 102 via the communication links124 and 125, respectively, when a prescription order has been received,processed, filled, and if applicable, deducted for in a patient'spayment account and/or shipped. Again, this may allow the healthcare hub102 to generate prescription status updates. Additionally oralternatively, notifications sent to the healthcare hub 102 from thepharmacies 106, 108 and specialty providers 109 provide the healthcarehub 102 with data that it can store, analyze, and/or report regardingthe speed, error rate, etc. of the respective pharmacies 106, 108 andspecialty providers 109. Such data enables the healthcare hub 102 toevaluate and benchmark pharmacy performance.

In other embodiments, the healthcare hub 102 sends requests for bidsrelated to particular medical goods or services to retail pharmacies106, mail order pharmacies 108, and/or specialty providers 109 via therespective communication links (122, 124 and/or 125). Additionally oralternatively, in some embodiments, the healthcare hub 102 providesvarious pharmacies 106, 108 and/or specialty providers 109 with accessto a bidding system, such as, for example, by sending an electronicinvitation or a link to a bidding website. In response, the retailpharmacies 106 and/or mail order pharmacies 108 may provide bids back tothe healthcare hub 102 via the respective communication links (122, 124and/or 125). In various embodiments, the bids are submittedelectronically to the healthcare hub 102 through a web-based portal.

In some embodiments, the communication links 122, 124, and/or 125 may betelephonic or facsimile connections. In a preferred embodiment, one ormore of the communication links 122, 124, and 125 are web-based and/orinternet-based connections.

In some embodiments, the healthcare hub 102 applies a rule engine,performs calculations, and/or performs comparisons to determine if aprescription is being filled by the best or lowest-priced retailpharmacy 106. If the healthcare hub 102 determines that one or morebetter options exist, the healthcare hub 102 of some embodimentsprovides information about the one or more better options to a callcenter 110 via a communication link 126. In some embodiments, the callcenter 110 is operated by an outside vendor operating under a contractwith the healthcare hub 102. In other embodiments, the call center 110is a call center facility, an individual employee, or an automatedcalling system operated by the healthcare hub 102. In other embodiments,the call center 110 may be a facility, company, individual or computerthat communicates with patients electronically via text messaging,emailing, mobile push notifications, or internet-based messaging. Thecall center 110 of some embodiments initiates a call or othercommunication with a patient 112 via communication link 136 to determineif the patient 112 would like to switch pharmacies. The call center 110of some embodiments also provides the patient 112 with additionalhealthcare tips, prescription reminders, healthcare adherence reminders,and/or other healthcare-related content after receiving such tips,reminders, and content from the healthcare hub 102 via the communicationlink 126. In some embodiments, the communication link 126 is a two-way(forward and reverse) communication link. For example, in someembodiments, the call center 110 transmits authorization information viacommunication link 126 back to the healthcare hub 102, indicatingwhether the patient authorized a pharmacy switch.

In some embodiments, the patient 112 can send patient-specificinformation, prescriptions received from a doctor 104, and/or healthcarequestions to the healthcare hub 102 via communication link 138. Thehealthcare hub 102 of some embodiments sends prescription status updatesto the patient 112 via the same communication link 138. In someembodiments, the healthcare hub 102 provides a web-based interfacethrough which a patient 112 can easily view all of the patient'sprescribed medical goods and services—even if several pharmacies andsuppliers are providing the various goods and services. In some suchembodiments, a patient logged into a web portal can track the status ofeach prescribed good and service and provide financial information tofacilitate the automatic payment of copays. Additionally oralternatively, in some embodiments, the healthcare hub 102 is configuredto provide answers to the patient's questions, feedback from a careteam, and/or health education content via communication link 138. Insome embodiments, the healthcare hub 102 will alert a patient 112 ofpotential drug interactions, remind a patient to adhere to a healthcareor wellness regimen, alert a patient 112 when healthcare goods orservices utilized by the patient 112 are available at a “betterpharmacy”, and/or provide a patient 112 with educational health andwellness tips. The healthcare hub 102 of some embodiments providespersonalized content related to disease states and/or health topics ofrelevance to a particular patient 112 via communication link 138. Insome such embodiments, the content is delivered to the patient in ahighly accessible format to empower the patient to make informed health,wellness, and healthcare decisions. For example, in some embodiments,communication link 138 is a wireless communication link, and content issent from the healthcare hub 102 to the patient 112 via text messagingor email or through a web-based portal or software application. In someembodiments, the healthcare hub 102 may connect the patient 112 directlyto a doctor 104, retail pharmacy 106, mail order pharmacy 108, specialtyprovider 109, or call center 110 in order to have the appropriate partyanswer the patient's questions. In some such embodiments, the patient112 exchanges information back and forth with the doctor 104, the retailpharmacy 106, the mail order pharmacy 108, the specialty provider 109,and/or the call center 110 via communication link 130, 132, 134, 135 and136, respectively.

In some embodiments, the doctor 104, the retail pharmacy 106, the mailorder pharmacy 108, the specialty provider 109, the call center 110, andthe patient 112 are all connected to the healthcare hub 102 via anetwork, for example, the Internet. In some embodiments, the patient 112is also connected to the doctor 104, the retail pharmacy 106, the mailorder pharmacy 108, the specialty provider 109, and the call center 110via a network, such as the Internet. In other embodiments, the patient112 exchanges information with the doctor 104, the retail pharmacy 106,the mail order pharmacy 108, the specialty provider 19, and/or the callcenter 110 via a telephonic connection or in-person interaction. Thus,it is to be appreciated that, in at least some embodiments, thecommunication links 120, 122, 124, 125, 126, 130, 132, 134, 135, 136,and 138 are representative of the communication functionality ratherthan physical connections.

In another embodiment of a healthcare needs fulfillment system, thesystem 200 is formed of one or more computers, such as one or moreservers 250 coupled via a communication network to at least one or moresupplier computers 230, one or more provider computers 220, and one ormore consumer computers 240. One example of such a system is provided inFIG. 2. Specifically, FIG. 2 illustrates a schematic diagram of thehardware components found in one embodiment of a healthcare needsfulfillment system 200 and includes a schematic illustration of theinteractions between said components. One skilled in the art willappreciate that the embodiment is illustrative in nature only andvarious components may be added, deleted, or substituted and variousdifferent hierarchies and modes of communication between the devices maybe employed. In the depicted example, the healthcare needs fulfillmentsystem 200 is formed of a plurality of computerized devices. The system200 includes a communication network 210 through which some or all ofthe various devices communicate with one another. In some embodiments, aplurality of the devices are configured to transmit information to, andreceive information from a server (i.e., the healthcare hub) 250 via thecommunication network 210. The network can be a local area network (LAN)or a wide area network (WAN). In some embodiments, the network is awireless communication network to which at least some of the devices areconnected, such as, for example, a mobile WiMAX network, LTE network,Wi-Fi network, or other wireless network. In other embodiments, thecommunication between at least some of the system devices and the server250 occurs over the internet via a wired network, such as a DSL cableconnection, or over Ethernet or an intranet.

In various embodiments, the system is accessible to users of the systemvia user workstations, such as provider workstations 220, supplierworkstations 230, and consumer workstations 240. The workstations may bespecialized computers configured solely for connection to the system200, or they may be generalized computers made to perform specializedfunctions through its connection to the system 200. For example, in someembodiments, the various workstations 220, 230, and 240 are desktopcomputers, laptop computers, and/or mobile devices such as tablets,smartphones, or wearable computing devices.

In various embodiments, the healthcare needs fulfillment system 200 isowned, operated, and/or managed by a prescription plan manager, such as,for example, a PBM, or other healthcare plan manager or other manager ofprescriptions or healthcare programs. The system may enable a planmanager to better manage a patient's prescribed treatments, improvepatients' adherence to healthcare treatments, reduce costs, and improveoutcomes. Using the system, a plan manager can easily review all of apatient's prescribed treatments (e.g., prescribed healthcare goods orservices) across providers and across suppliers. Regardless of whoprescribes the treatment and who supplies the treatment, the list oftreatments is available in one readily accessible location. A patient'shealth profile may also be available within the system. Thus, in suchembodiments, plan managers and providers can review a patient'sdiagnoses and prescribed treatments and identify any treatment gaps,e.g., recommended treatments the patient is not currently receiving. Ifa treatment gap is identified by the patient's provider, the providermay submit an additional prescription to the system 200. If thetreatment gap is identified by the plan manager, the plan manager canutilize the system 200 to contact the patient's provider and recommendthe treatment.

Additionally, in various embodiments, the system 200 fills many of theconsultative roles previously filled by a retail pharmacy or localsupplier. In certain embodiments, the system 200 provides a repositoryof health-related content and curates it for the patient, such thatinformation helpful to the patient is easily accessible to the patient.Adherence reminders and health suggestions may also be delivered to thepatient. The patient may also be able to submit health andtreatment-related questions through the system 200 to the plan manager,such that the patient no longer feels a need to visit and speak with alocal pharmacist. Advantageously, in some such embodiments, the system200 acts as an intermediary; with no direct communication betweensuppliers and patients, the plan manager is able to assign prescriptionsto suppliers without regard for patient-supplier relationships; thus,the plan manager achieves more flexibility in sourcing prescriptions.Such a system enables plan managers to send prescriptions to the bestsupplier for the patient, with “best” being a patient-specificdetermination that may include variables such as, for example, price,disease-specific expertise, quality ratings, and/or speed offulfillment. Such a system also enables plan managers to reevaluatesuppliers and transfer prescriptions whenever the plan manager deems itto be appropriate.

In certain embodiments, the system 200 also handles all paymentsautomatically by storing a consumer's financial account information,calculating copayments, deducting copayments from patients' accounts,and depositing payments into suppliers' accounts, thus furthersimplifying interactions between patients and suppliers. In someembodiments, efficiency in interactions is further improved throughimproved adjudication procedures. In some such embodiments, thehealthcare hub/server 250 adjudicates a prescription immediately uponreceipt from a provider. In such embodiments, the prescription iscompared to patient and plan information stored within the server 250 toidentify the patient's plan, confirm that the patient is eligible toreceive the prescribed treatment under the patient's plan, and confirmthat there are no known adverse interactions between the prescribedtreatment and other treatments currently being provided to the patient.Such embodiments eliminate the need for suppliers to later submit theprescription for authorization and payment.

In various embodiments, the server 250 includes a processor and memory,and software code is stored in the memory, which, when executed by theprocessor, causes the system to perform system functions, such as, forexample, any of the methods and processes described throughout thedisclosure provided herein. In some embodiments, the server 250 includesan application server. In some such embodiments, some software code isstored in the server 250, while additional software code is stored oneach other network-connected device (e.g., 220, 230, 240) in the form ofa software application. In some such embodiments, “back end” functionssuch as storing information sets in databases and performingcalculations, analyses, and information retrieval is largely performedby, and coded for, within the server 250, while “front end” functions,such as the display of information on a graphical user interface (GUI)and receipt of user inputs, is performed by, and encoded within, theother network-connected devices (220, 230, 240). Additionally oralternatively, in some embodiments, the server 250 includes a web serverand various features and functionality are made possible by the softwarecode stored within the server 250. In some such embodiments, each userworkstation 220, 230, 240 may include an internet browser, through whichusers can access, and interact with, the healthcare needs fulfillmentsystem 200. In various embodiments, the server 250 also includes adatabase server on which information sets such as patient profiles,patient health records, supplier price lists, lists of other suppliermetrics, information about various therapies, therapy classifications,known contraindications of therapies, and a repository of content arestored. It will be appreciated to one skilled in the art that the server250 may be formed of any suitable number of servers. For example, insome embodiments, the server 250 includes one or a plurality ofapplication servers, one or a plurality of web servers, and/or one or aplurality of database servers.

As depicted in FIG. 2, the various devices of the system 200 interactwith the network 210, and accordingly, each other, via a two-way(forward and reverse) communication link. The devices each includeinput/output devices for wired communication connections (e.g., modems,network cards, external data buses, ports, etc.) and/or wirelessreceivers and transmitters, which allow each device to transmit andreceive information. Exemplary information exchanged by the variouscomponents is described in more detail below. These are examples only,and various other information exchanges are conceived and expresslycontemplated herein.

In certain embodiments, the provider workstation 220 has an input/outputdevice (e.g., mouse, keyboard, touchscreen, monitor, etc.) allowing itto receive inputs from a provider user and display graphical outputs.Users, such as doctors, nurses, nurse practitioners, or employees orcontractors of a medical practice or medical facility, may enterprescriptions for patients into the system 200 through the providerworkstation 220. In some embodiments, the users of a providerworkstation 220 additionally enter a patient's healthcare history,diagnoses, or other information from a patient's medical records intothe system 200. Such information is transmitted to the server 250 viathe communication network 210 for storage, and optionally, forprocessing. Users of the provider workstations 220 may also receiverequests to verify patient information, authorize a switch for a patientfrom a brand name healthcare product to a generic equivalent, confirmthat a prescription is correct if the system identifies that it isinconsistent with the patient's diagnoses or if a potential adversereaction is detected with another prescription or an allergy of thepatient. Users of the provider workstations 220 may also connect to thesystem 200 in order to access content about various therapies and otherhealth-related information.

The supplier workstations 230 also have input/output devices (e.g.,mouse, keyboard, touchscreen, monitor, etc.) for receiving inputs fromusers and displaying graphical outputs to users. The workstations 230may receive requests from the system 200 to submit pricing lists, listsof ancillary services offered, or quality-related information such as,for example, average number of prescriptions filled in a specified timeperiod, average speed for filling prescriptions, etc. Suppliers may beable to submit information relevant to such requests to the system 200via the supplier workstations 230, and such information may be processedand stored in the server 250. The workstations 230 may also receiverequests from the system 200 to participate in competitive biddingprocesses. Such requests are presented to a user of the supplierworkstations 230 via a GUI. Such requests may be in the form of a linkthat connects users to a competitive bidding interface present withinthe system. Through the workstations 230, suppliers also receiveprescriptions for fulfillment and transmit status updates when theprescriptions have been: received, filled, and shipped. A trackingnumber may also be transmitted with the status update at the time ofshipment. In some embodiments, the suppliers also transmit billingand/or financial account information for storage within the server 250such that, upon fulfillment or shipment of a prescription, the suppliercan receive payment automatically.

In various embodiments, in order for a supplier workstation 230 to jointhe healthcare needs fulfillment system 200, the supplier must complywith certain minimum service requirements and/or connectivityrequirements. As an example, the minimum service requirements mayinclude, but are not limited to, prescription fulfillment within a firstspecified time period, such as a day, and deliver to a patient within asecond specified time period.

Regarding connectivity requirements, in some embodiments, in order tojoin the system 200, the supplier workstation 230 must download certainsoftware and demonstrate that it is able to successfully receiveelectronic messages from the healthcare hub/server 250 and reply to suchmessages. For example, in one embodiment, the supplier workstation 230much establish connectivity through an HTTP Web Request/Response andformat messages with an XML body. In certain embodiments, the replymessages must conform to a specified format to ensure seamlesscommunication within the system. As one example, in some embodiments,the supplier workstation 230 must prove that it is able to receive a newprescription message from the server 250 and identify all data includedin the message. In some embodiments, a new prescription message willfollow the same or similar format as an Industry ERx Switch New RxMessage or other format commonly used in the industry. The message ofvarious embodiments will include all data elements needed to fill theprescription and may include additional elements. For example, themessage may include some or all of: a patient's name, date of birth,gender, shipping address, the name and quantity of the prescribed goodor service, the patient's health coverage information such as a groupcode, BIN number, a prescription drug's PCN, if applicable, a patient'sdiagnoses and/or known allergies, and information about the transferringpharmacy, if applicable. In certain embodiments, in order to join thesystem 200, the supplier workstation 230 must also demonstrate that itis able to generate a new prescription number and construct a replymessage confirming receipt of the prescription within 60 seconds (orother specified time interval), wherein the reply message includes thenew prescription number. In some embodiments, the new prescriptionnumber must be unique to any other prescription received by the supplieron that date; the prescription order will remain the same for the lifeof the prescription. The server 250 of some embodiments will store theprescription number. In some embodiments, the supplier must alsodemonstrate that it is able to receive a refill request messagecontaining the prescription number, find the original prescriptionassociated with the refill request, respond to the refill requestmessage within a specified time period, and successfully refill theprescription. Additionally, the supplier workstation 230 may be requiredto demonstrate that it can send status messages for prescriptionreceipt, fulfillment, shipment, and optionally, delivery, as suchtrigger events occur. The shipment message of some embodiments mustinclude a carrier and tracking number. In various embodiments, uponreceipt and processing of the status messages by the server, the statusimmediately updates within the system and data transmitted to a providerworkstation 220 or consumer workstation 240 reflects the update. In someembodiments, the supplier workstation 230 must also demonstrate that ithas properly encrypted all messages, for example, using an encryptionprocess such as the X509 XML encryption process.

In various embodiments, each consumer workstation 240 has one or moreinput/output devices (e.g., mouse, keyboard, touchscreen, monitor, etc.)for receiving inputs from a patient and/or a patient's parent, guardian,or caregiver and for displaying graphical outputs to such consumers.Upon request by a consumer through interaction with a GUI, a consumerworkstation 240 may receive patient-specific prescription informationstored in the server 250. Such information may be displayed to theconsumer for review. For example, the consumer may be able to view allof a patient's prescriptions within a single GUI, includingprescriptions filled by diverse, unaffiliated suppliers. The displayedinformation may include, for example, whether a prescription is due forfulfillment, and if so, whether the prescription has been received,fulfilled, and/or shipped by a supplier. In various embodiments, theprescription will be automatically transmitted to a supplier for refillwhen it is due for refilling. The consumer may also be able to view thenumber of refills remaining in a prescription, the date the prescriptionwill expire, and similar information. The workstations 240 may alsoreceive patient profile information from the server 250, which isdisplayed to the consumer for review and/or editing; the workstations240 may further transmit patient profile data to the server 250 in orderto add to, or update, the stored information. Additionally, in someembodiments, consumers are able to access content, such as, for example,health-related articles, quizzes, games, and mobile or web-basedsoftware applications from the server 250 through the consumerworkstation 240. Consumers may also be able to transmit questions to theserver 250 through the consumer workstation 240. Such questions aretriaged and transmitted to a supplier, provider, and/or plan manager forresponse. Additionally or alternatively, in some embodiments, a consumermay be able to transmit financial account information via the consumerworkstation 240 for storage within the server 250, thereby enablingautomatic payments to be made when a prescription has been filled,shipped, or delivered.

In another embodiment of the healthcare needs fulfillment system, thesystem 300 is formed of one or more servers or other back-end computingdevices that drive the operations. The server of such embodiments isconfigured to receive information from, and send information to, variousremote components, and is further configured to store data and executestored instructions, enabling the system to perform some or all of thefunctions and methods described herein. A functional block diagram ofone such embodiment of the healthcare needs fulfillment system isdepicted in FIG. 3. Although described separately, it is to beappreciated that functional blocks described with respect to thehealthcare needs fulfillment system 300 need not be separate structuralelements. For example, the processor 310 and memory 320 may be embodiedin a single chip. Similarly, the processor 310 and network interface 350may be embodied in a single chip. Likewise, the receiver 352 andtransmitter 354 may be embodied in a single chip.

The processor 310 can be a general purpose processor, a digital signalprocessor (DSP), an application specific integrated circuit (ASIC), afield programmable gate array (FPGA) or other programmable logic device,discrete gate or transistor logic, discrete hardware components, or anysuitable combination thereof designed to perform the functions describedherein. A processor may also be implemented as a combination ofcomputing devices, e.g., a combination of a DSP and a microprocessor, aplurality of microprocessors, one or more microprocessors in conjunctionwith a DSP core, or any other such configuration.

The processor 310 is coupled, via one or more buses, to read informationfrom or write information to the memory 320. The processor mayadditionally, or in the alternative, contain memory, such as processorregisters. The memory 320 can include processor cache, including amulti-level hierarchical cache in which different levels have differentcapacities and access speeds. The memory 320 can also include randomaccess memory (RAM), other volatile storage devices, or non-volatilestorage devices. The storage devices can include hard drives, opticaldiscs, such as compact discs (CDs) or digital video discs (DVDs), flashmemory, floppy discs, magnetic tape, and Zip drives.

The processor 310, in conjunction with software stored in the memory 320executes an operating system, such as, for example, Windows, Mac OS,Unix or Solaris 5.10. The processor 310 also executes softwareapplications stored in the memory 320. For example, the functionalityfor identifying one or more suggested pharmacies for a patient can beprogrammed as software stored in the memory 320. In one non-limitingembodiment, the software comprises, for example, Unix Korn shellscripts. In other embodiments, the software can be programs in anysuitable programming language known to those skilled in the art,including, for example, C++ and Java.

In one embodiment, the memory 320 may include software for operating thehealthcare needs fulfillment system 300 as a web server, such as forexample, the software provided by Apache and Tomcat. In one embodiment,the memory 320 includes a web-accessible database, that is, a databasewhich is accessible via the network interface 350. Software stored inthe memory 320, such as for example, Oracle 10g, provides databaseservices to the processor 310 and to users of the healthcare needsfulfillment system 300.

The processor 310 is also coupled to an input device 330 and an outputdevice 340 for, respectively, receiving input from and providing outputto, a system administrator of the healthcare needs fulfillment system300. Suitable input devices include, but are not limited to, a keyboard,buttons, keys, switches, a pointing device, a mouse, a joystick, aremote control, an infrared detector, a video camera (possibly coupledwith video processing software to, e.g., detect hand gestures or facialgestures), a motion detector, and a microphone (possibly coupled toaudio processing software to, e.g., detect voice commands). Suitableoutput devices include, but are not limited to, visual output devices,including displays and printers, audio output devices, includingspeakers, headphones, earphones, and alarms, and haptic output devices,including force-feedback game controllers and vibrating devices.

The processor 310 may be further coupled to a network interface 350,including a receiver 352 and a transmitter 354. The transmitter 354, inconjunction with the network interface 350, prepares data generated bythe processor 310 for transmission over a communication networkaccording to one or more network standards. The receiver 352, inconjunction with the network interface 350, demodulates data receivedover a communication network according to one or more network standards.In one embodiment, the transmitter 354 and the receiver 352 are part ofthe same component, such as, for example, a transceiver. In otherembodiments, the transmitter 354 and receiver 52 are two separatecomponents.

FIG. 4 provides a flowchart illustrating one embodiment of a method 400for fulfilling and managing prescriptions performed by the healthcareneeds fulfillment system 300 of FIG. 3. In the illustrated embodiment,the healthcare needs fulfillment system receives a prescription from auser, as shown in block 402. The prescription includes, at least, thename of a prescription drug or medical good or service and, ifapplicable, a dosage and/or prescribed frequency of use, as prescribedby a healthcare professional for a patient. In some embodiments, theuser submits an electronic prescription to the healthcare needsfulfillment system by logging into a web-based or mobile applicationinterface and entering the electronic prescription into appropriatewindows or boxes within the web-based interface. The electronicprescription is transmitted to the healthcare needs fulfillment systemover a network connection. In other embodiments, the prescription may beemailed, faxed, or called in to an operator of the healthcare hub. Ahuman or computer affiliated with the healthcare hub can then input theprescription information into the healthcare needs fulfillment system.

In some embodiments, the healthcare needs fulfillment system alsoreceives patient information from a user, as shown in block 404. Thepatient information may also be entered electronically into a web-basedor mobile application interface and transmitted to the healthcare needsfulfillment system via a network. Alternatively, the patient informationmay be called in, faxed, or emailed to the healthcare hub along with theprescription. The patient information of some embodiments includes, atleast, an identifier linking the patient to the patient's respectiveinsurance and/or prescription drug plan. In some embodiments, theidentifier simply comprises the patient's name and the group number ormember code of the patient's insurance and/or prescription drug plan.

In other embodiments, the identifier is a username or access ID, whichuniquely identifies the patient and links the patient to apatient-specific data space within the memory of the healthcare needsfulfillment system. In such embodiments, the patient-specific data spacestores data pertaining to a patient-specific profile. Thepatient-specific profile of some embodiments is maintained by thehealthcare needs fulfillment system and accessible by the patient viathe web-based or mobile application interface. In some embodiments, thepatient-specific profile is editable by the patient and/or the patient'sphysician. The patient-specific profile of some embodiments includespatient-specific information, including at least the patient's:prescription benefit or other health plan, birthdate, name, address, andcurrent prescriptions. In some embodiments, the patient-specific profilemay also include the patient's medical history or other biographicalinformation. In some embodiments in which a patient-specific profile ispresent, the healthcare needs fulfillment system creates or updates apatient-specific profile upon receiving patient information from a user.

Returning to FIG. 4, after receiving a prescription and patientinformation from a user, the healthcare needs fulfillment systemaccesses a database of pricing data for medical goods and services, asindicated by block 406. In some embodiments, the database of pricingdata is stored remotely from the healthcare needs fulfillment system andis accessed via a network, such as the Internet. In other embodiments,the database of pricing data is stored within the memory of thehealthcare needs fulfillment system. In some embodiments, the databaseincludes listings of current drug prices, listed by drug and bypharmacy. In some embodiments, the database includes listings of currentprices for various medical goods and services, listed, for example, bymanufacturer, trade name, and supplier. These prices reflect the pricesat which each listed supplier has agreed to sell each listed drug orother medical good or service. In some embodiments, the current pricesare updated whenever a supplier submits a revised list of prices. Inother embodiments, the current prices are updated periodically uponreceiving bids from a plurality of bidding suppliers. Such a biddingprocess is described in more detail below with reference to FIGS. 8A and8B.

As depicted in block 408, in some embodiments, the healthcare needsfulfillment system identifies one or more suggested pharmacies or othersuppliers by evaluating all suppliers listed within the database based,at least in part, on: (1) the prescription product name, and ifapplicable, the prescribed dosage, prescribed amount, and/or prescribedfrequency of use, as identified in the prescription, (2) the patient'sprescription benefit plan identified from the patient information, and(3) the current pricing data provided in the database of pricing datafor medical goods and services. From this information, the healthcareneeds fulfillment system of some embodiments can identify one or moresuppliers that will fill the patient's prescription most cheaply.

In other embodiments, the one or more suggested suppliers may beidentified taking into account more than just price. For example, insome embodiments, the healthcare needs fulfillment system also takesinto account the address of each supplier listed within the database andthe address of the patient. The supplier addresses may be stored in adatabase of supplier information within the memory of the healthcareneeds fulfillment system. The patient's address may be stored within thepatient-specific profile. In such embodiments, the one or more suggestedsuppliers identified by the system may include, for example, the threesuppliers that will fill the prescription most cheaply within a 3-mileradius of the patient. In other embodiments, the system may beconfigured to identify a different number of suggested suppliers and/oruse a different distance/radius in its calculations. In someembodiments, the healthcare needs fulfillment system additionally oralternatively takes into account other data stored within the databaseof supplier information when identifying one or more suggestedsuppliers. For example, in some embodiments, the healthcare needsfulfillment system identifies suggested suppliers based, at least inpart, on the expertise, historical performance, and/or quality rating ofeach supplier. In some embodiments, the healthcare needs fulfillmentsystem monitors and stores metrics indicative of performance assuppliers use the system. For example, in some embodiments, the systemmonitors and stores the length of time it takes a supplier to fill aprescription, the number of errors or issues that arise, the percent ofpatients that report adherence to treatment, improved health,satisfaction with their supplier etc. In some embodiments, thehealthcare needs fulfillment system takes into account a patient'sdiagnoses and/or all of a patient's prescriptions, as a bundled package,when evaluating suppliers based on criteria such as price, location,availability, quality, and/or expertise. In this manner, the system mayidentify one or more suggested suppliers best aligned for managing apatient's conditions and all of a patient's prescribed healthcare needs.

In some embodiments, the healthcare needs fulfillment system providesthe user with a list of suggested suppliers, as shown in block 410, andreceives a user input, as shown in block 412, indicating which suggestedsupplier the user has selected to be the patient's new supplier. Thelist may be transmitted to the user over the Internet and displayed tothe user via the web-based or mobile application interface. Similarly,using the web-based or application interface, the user can provide aninput to select the new supplier. In some embodiments, only retailpharmacies and/or specialty providers are shown in the list of suggestedsuppliers. In other embodiments, mail-order is included as one of theuser's options in the list of suggested suppliers. Upon receiving theuser's input identifying the suggested supplier selected to be thepatient's new supplier, the prescription is sent in electronic form tothe selected new supplier, as shown in block 414.

In some embodiments of a method for fulfilling and managingprescriptions performed by a healthcare needs fulfillment system, theoperations disclosed in blocks 410 and 412 are not included. In suchembodiments, after receiving a prescription and patient information froma user and accessing a database of pricing data for prescription drugsand/or other medical goods or services, the healthcare needs fulfillmentsystem identifies one suggested supplier at block 408. As describedabove, the suggested supplier determination may be based on a supplier'sprice for a particular good or service, proximity to the patient,particular expertise, speed of fulfillment, availability of the good orservice, quality rating, overall price or quality for a bundle ofprescriptions, and/or other factors. Once the suggested supplier isidentified, the prescription is sent electronically to that supplier.

In some embodiments, the method for fulfilling and managingprescriptions further includes tracking the status of the prescriptionthrough the pipeline. That is, in some embodiments, the status of theprescription can be tracked electronically as the selected supplierreceives, fulfills, bills for, and/or ships the prescription. Such anoperation is shown at block 416. If the selected supplier is a mailorder supplier, the healthcare needs fulfillment system may additionallybe able to track the status of the shipping process from drop off todelivery. In some embodiments, the selected supplier providesnotifications to the healthcare needs fulfillment system when the statusof the prescription has changed, thereby allowing the healthcare needsfulfillment system to track the status of the prescription. In someembodiments, the status of the prescription is viewable by the userthrough the web-based or mobile application interface.

FIG. 5 provides a flowchart illustrating another embodiment of a methodfor fulfilling and managing prescriptions. In the depicted method 500,the healthcare needs fulfillment system receives a processed claimrecord from a payer, PBM, or claim aggregator at block 502. Theprocessed claim record includes information about at least oneprescription fulfilled at a pharmacy. The processed claim record atleast identifies the fulfilling pharmacy, the patient, and theprescribed good or service for each fulfilled prescription. From thisinformation, and optionally, from additional patient information storedin a patient-specific profile, the healthcare needs fulfillment systemgenerates an eligible claim switch file as shown at block 504. Theeligible claim switch file identifies one or more prescriptions that maybe good candidates for transfer to another pharmacy.

At block 506, the eligible claim switch file is sent to a pharmacyevaluator. The pharmacy evaluator of some embodiments is an outsidevendor. In some embodiments, the eligible claim switch file is sent tothe pharmacy evaluator via the web-based or mobile applicationinterface. In other embodiments, the pharmacy evaluator is a sub-systemof the healthcare needs fulfillment system, and the eligible claimswitch file is sent to the pharmacy evaluator via a LAN, intranet, orelectronic connection. The pharmacy evaluator generates a reportidentifying one or more suggested pharmacies. The one or more suggestedpharmacies are pharmacies that would fulfill the prescription mostoptimally, as determined by taking into account one or more factors.Such factors may include, for example, a pharmacy's pricing, proximityto the patient, particular expertise, speed of fulfillment, availabilityof the good or service, quality rating, and/or performance rating. Atblock 508, the healthcare needs fulfillment system receives the reportfrom the pharmacy evaluator identifying one or more suggestedpharmacies.

At block 510, the healthcare needs fulfillment system evaluates whetherthe patient is a target patient. In various embodiments, the patient isfound to be a target patient if the fulfilling pharmacy listed in theprocessed claim record is not listed within the report of suggestedpharmacies. Such a finding indicates that the patient's prescription isnot currently being filled optimally. For example, such a finding maysuggest that one or more pharmacies are closer to the patient, cheaperfor the patient, have more expertise with a particular health conditionof the patient, and/or are better able to manage a patient's entirebundle of prescriptions than the patient's current pharmacy. In someembodiments, additional considerations are taken into account whendetermining whether a patient qualifies as a target patient. Forexample, in some embodiments, the healthcare needs fulfillment systemdetermines whether the patient is permitted to transfer prescriptionsunder the patient's prescription benefit plan. In one example, thehealthcare needs fulfillment system excludes all Medicare Part Drecipients from the target patient population.

As shown at block 512, if the patient is not identified as a targetpatient, the patient will not be contacted to discuss a prescriptiontransfer and the patient's prescriptions will not be transferred. If thepatient is identified as a target patient, as in block 514, the patientwill be included within a list of target patients that the healthcareneeds fulfillment system sends to a caller. The list will include, atleast, the patient's name, the patient's contact information, thepatient's prescription, and the one or more suggested pharmacies. Insome embodiments, the caller is an outside vendor contracted to makecalls for the healthcare needs fulfillment system. In some suchembodiments, the list of target patients is provided to the caller via aweb-based or application interface. In other embodiments, the caller isan automated calling sub-system, which forms part of the healthcareneeds fulfillment system. The list of target patients may be provided tothe sub-system, for example, via a LAN, intranet, or electronicconnection. In some embodiments, the caller contacts each target patientincluded on the list to determine if each target patient would like totransfer the patient's respective prescription to one of the suggestedpharmacies. The caller may contact each target patient via phone, email,text-message, push notification, or mail. In some embodiments, thecaller provides the target patient with the location and/or the requiredcopay associated with each of the suggested pharmacies to better informthe patient's decision.

In some embodiments of the method, the healthcare needs fulfillmentsystem receives a notification from the caller when a target patientauthorizes a transfer of the patient's prescription to one of thesuggested pharmacies, as shown at block 516. The healthcare needsfulfillment system contacts the pharmacy selected by the target patientand transfers the prescription for the patient, as shown at block 518.Conversely, in other embodiments, when a target patient in contact withthe caller authorizes a prescription transfer, the target patient isinstructed to bring the prescription to the selected pharmacy. In otherembodiments, when a target patient in contact with the caller authorizesa prescription transfer, the caller contacts the selected pharmacy andtransfers the prescription for the patient.

FIG. 6 is a flowchart illustrating another embodiment of a method forfulfilling and managing prescriptions. In the method 600 of FIG. 6, thehealthcare needs fulfillment system receives prescription and patientinformation from a user, as described above in the description of FIG.4. Upon receiving the information at block 602, the healthcare needsfulfillment system updates a patient-specific profile to include atleast some of the information received at block 602. As shown at block604, if a patient-specific profile does not yet exist for a particularpatient, the healthcare needs fulfillment system of some embodimentswill generate a patient-specific profile upon receiving patientinformation from the user.

At block 606, the healthcare needs fulfillment system performs aprescription authorization and/or eligibility check. In someembodiments, the authorization check includes comparing the receivedprescription to the patient information to determine, for example,whether the prescribed good or service, and dosage or frequency of use,if applicable, is consistent with the patient's diagnosis and/or whetherthe prescribed good or service might cause adverse effects with otherprescriptions of the patient. In some embodiments, the eligibility checkincludes verifying the patient's insurance or prescription benefits planand/or determining whether the prescribed good or service is covered bythe patient's plan. Additionally or alternatively, in some embodiments,where applicable, the authorization check includes contacting thepatient's physician to determine whether a generic drug is an acceptablesubstitute for a brand name drug. The prescription authorization checkof some embodiments is fully automated. In other embodiments, at least aportion of the prescription authorization check is performed by ahealthcare needs fulfillment system administrator.

At optional block 608, the healthcare needs fulfillment system receivesa patient's preference for mail-order or a particular retail pharmacy.Upon receiving the preference, the healthcare needs fulfillment systemprocesses the preference at block 610.

If the patient selected to receive the prescription via mail order, orif optional block 608 is not present in the system, the healthcare needsfulfillment system chooses a mail-order pharmacy or other supplier to bethe provider of the prescription, as shown at block 612. The chosenmail-order supplier may be selected at least in part via a biddingsystem, as described in detail below with reference to FIGS. 8A and 8B.Additionally, or in the alternative, the chosen mail-order supplier maybe selected through an evaluation process which weighs one or morecriteria such as, for example, the prescription sales prices, qualityratings, safety ratings, and expertise of various suppliers. At block614, the healthcare needs fulfillment system sends the prescription tothe selected mail-order supplier.

Optionally, in some embodiments, the healthcare needs fulfillment systemdeducts payment for the prescription copay from the patient's bankaccount (or charges the payment to the patient's credit card) as shownat block 616. To make the operation shown at block 616 possible, apatient's financial account information must be stored in thepatient-specific profile. In some embodiments, a patient can add ormodify financial account information and/or other patient informationincluded in the patient-specific profile at any time via the web-basedinterface.

In some embodiments, the healthcare needs fulfillment system tracks thereceipt, fulfillment, payment, and/or shipment of the prescription bythe mail order pharmacy or other supplier, as shown at block 618. Thehealthcare needs fulfillment system of such embodiments providesprescription status updates, which the patient or other user of thesystem can access.

If, at block 610, the healthcare needs fulfillment system determinedthat the patient selected a particular retail pharmacy, the methodproceeds to block 620, and the prescription is sent to the retailpharmacy selected by the patient for fulfillment. Upon receiving anapproved claim record from a payer, PBM, or claim aggregator (see block622), a method similar to the method embodied in FIG. 5 is performed. Atblocks 624 and 626, the healthcare needs fulfillment system determineswhether the prescription was filled by the best pharmacy for thepatient. This determination is performed by identifying one or more“best” or suggested pharmacies, based on factors such as price,proximity to the patient, availability of the prescribed good orservice, speed of fulfillment, pharmacy performance, and/or pharmacyexpertise and comparing the patient-selected pharmacy to the identifiedbest pharmacies. As described previously, in some embodiments, anoutside vendor identifies one or more suggested pharmacies for fillingthe patient's prescription. The healthcare needs fulfillment system thendetermines whether the prescription was filled by the best pharmacy forthe patient by evaluating whether the patient-selected pharmacy isincluded in the vendor's list of one or more suggested pharmacies.

In some embodiments, if it is determined that the prescription wasfilled by one of the best or suggested pharmacies, the healthcare needsfulfillment system will auto-authorize refills of the prescription bythe current pharmacy in the future (as shown at block 628). If, on theother hand, it is determined that the prescription was not filled by oneof the best or suggested pharmacies, the method proceeds to block 630.In some embodiments, a list of suggested or better pharmacies isprovided to a caller. As before, the caller may be a person or acomputerized system, and the caller may be an outside vendor or asubsystem of the healthcare needs fulfillment system. In someembodiments, after the caller contacts the patient (via phone, fax,email, text, push notification, etc.) and receives a response from thepatient, the response is forwarded to the healthcare needs fulfillmentsystem. At block 632, the system receives the patient's response fromthe caller. At block 634, the healthcare needs fulfillment systemanalyzes the patient's response to determine whether the patientrequested a prescription transfer to a new pharmacy. As shown at block636, if the patient requested a transfer, the healthcare needsfulfillment system of some embodiments transfers the prescription to thenew pharmacy. In some embodiments, if the patient does not request atransfer, the healthcare needs fulfillment system will auto-authorizerefills of the prescription by the current pharmacy in the future (asshown at block 638).

FIG. 7 depicts another embodiment of a method performed by a healthcareneeds fulfillment system to fulfill and manage patient prescriptions. Insome embodiments, the method 700 is implemented by a healthcare hub,which may be, for example, a computer that is owned, managed, and orcontrolled by a plan manager and programmed to concurrently manageprescriptions for a multitude of patients. In the embodiment of FIG. 7,the computer implementing the method 700 receives prescriptions for apatient from one or more users' computers at block 702. Theprescriptions may be received, for example, from the patient's computerand/or a provider's computer. Each of the prescriptions identifies thepatient and a prescribed treatment. At block 704, the computeridentifies the patient from each prescription, for example, by locatingpatient identifying information on the prescriptions. At block 706, thecomputer searches an internal or external database to identify a plan towhich the particular patient belongs. At block 708, the computeradjudicates the prescription and performs prior authorization forfulfillment. For example, in some embodiments, the computer confirmsthat the patient is eligible for each prescribed healthcare good orservice and verifies that the patient's plan covers the prescribed goodor service. Such verification may again require looking up required plancoverage data within an internal or external database. At block 710, thecomputer searches a database maintained by the plan manager to identifysupplier selection criteria associated with the patient's plan. Thesupplier selection criteria may vary with each plan or each plan payer,or the same criteria for selection may be used across all plans. Theselection criteria may also vary with each healthcare good or service.Such criteria are described elsewhere herein and may include, forexample, a preference to select the supplier offering: the lowest price;the lowest price among suppliers with a certain quality rating; thelowest price among suppliers identified as having an expertise with aparticular health condition; the lowest price among suppliers offering aparticular ancillary service, the greatest number of ancillary servicesand the prescribed good or service at the lowest price; or the lowestprice among a limited set of suppliers preferred by the plan payer.

At blocks 712 and 714 of the depicted embodiment, the computer selectsand applies supplier selection criteria in order to select one or moresuppliers to fill one or more of the patient's prescriptions. At block716, the prescriptions are transmitted to the chosen suppliers forfulfillment. Advantageously, in some embodiments, the prescriptions aretransmitted with pre-approval/prior authorization such that the chosensuppliers do not need to later seek authorization to fill theprescriptions. Instead, the chosen suppliers begin fulfillment of theprescription and send status updates to the computer as updating eventsoccur. For example, as shown at block 718, the computer receivesprescription receipt confirmations, fulfillment confirmations, andshipment confirmations from each of the chosen suppliers, uponcompletion of each step. In some embodiments, the computer also receivesdelivery confirmation when delivery to a patient has been completed. Atblock 720, the computer transmits the status updates to a patient orrelated user's computer. In various embodiments, the status updates aretransmitted in a format through which updates from all chosen suppliersare together viewable by the patient or related user within a singleuser interface. For example, in some embodiments, the status updates aredisplayed on or accessible from a single page within a web-based ormobile application.

In some embodiments, the computer also calculates a copayment price owedby the patient for each of the patient's prescriptions, as shown atblock 722. In some such embodiments, the computer accesses accountinformation for a financial account of the patient from an internaldatabase (block 724), deducts the copayment price from the financialaccount (block 726), and transmits a payment to each of the chosensuppliers (block 728). In some embodiments, the payment is transmittedby the computer along with a plan payer's portion of the payment.Advantageously, in some such embodiments, all information and payments asupplier needs are received from the healthcare hub rather than from thepatient.

FIG. 8A is a flowchart illustrating an embodiment of a method performedby a healthcare needs fulfillment system for identifying preferredsuppliers and fulfilling prescriptions using said preferred suppliers.In the illustrated embodiment of the method 800, the healthcare needsfulfillment system employs a bidding process to help identify thepreferred suppliers. For example, in block 802, the healthcare needsfulfillment system provides various suppliers with access to the biddingprocess covering a next pricing cycle. In some embodiments, the pricesare set quarterly, so the next pricing cycle is equivalent to the nextfiscal or calendar quarter. In other embodiments, other pricing cyclesare used, such as, for example, daily, weekly, monthly or annually. Invarious embodiments, access may be provided to certified suppliers viaan electronic link received by email or through a web-based orapplication interface. Certified suppliers may include suppliers thathave met certain service and connectivity requirements, such as thosedescribed above with reference to FIG. 2. The certified suppliers maychoose whether to participate in the bidding process and become“participating suppliers.” To participate in the bidding process, insome embodiments, certified suppliers must follow the electronic link toa secure bidding interface, which may be web-based or softwareapplication-based. In other embodiments, the electronic link directscertified suppliers to a downloadable file in which suppliers can entertheir bids and return to a healthcare hub/plan manager through aweb-based or application interface or via an electronic message such asemail.

At block 804, the healthcare needs fulfillment system receives completedbids for the next pricing cycle from a plurality of participatingsuppliers. Each completed bid includes, at least, the price therespective supplier will charge for each prescribed good or service. Insome embodiments, the completed bids additionally include the price thesupplier will charge for each formulation and dosage, if applicable,and/or price variations the supplier will charge based on a patient'spharmacy benefits plan. In some embodiments, bids are submitted on a perunit basis. For example, in some embodiments, all bids for medical goodsand services are listed as: per tablet, per capsule, per test strip, perMRI, per X-ray, etc. In some such embodiments, the per unit basis is theonly price the healthcare needs fulfillment system will consider.Accordingly, in such embodiments, each bidder must sum up all costs theywish to be reimbursed for, such as, for example, the wholesale cost ofthe good or service, shipping costs, dispensing fees, etc., then performdivision to determine the cost per unit. By requiring all bids to besubmitted on a per unit basis, the healthcare needs fulfillment systemis able to easily and efficiently compare costs across suppliers.Additionally, in some embodiments, participating suppliers may be ableto list ancillary services they are willing to provide patients alongwith the prescription fulfillment.

At block 806, the healthcare needs fulfillment system compares thecompleted bids to identify the preferred supplier for each good orservice, and in some embodiments, for each formulation, each dosage orsize, and/or each pharmacy benefits plan or other health plan. As inother embodiments, the preferred supplier may be selected based onvarious factors, such as, for example, a supplier's prices, fulfillmentspeed, quality, error rates, and expertise. Information related to oneor more of the above-listed factors or other factors may need to beprovided by suppliers during the bidding process. In some embodiments,some of the above-listed factors may be collected and storedautomatically by the system during use. In some embodiments, the biddingis an open process, allowing the participating suppliers to view thebids of their competitors. In some such embodiments, the bidding isiterative, allowing participating suppliers to submit multiple bids foreach healthcare good or service during the duration of the bidingprocess. In other embodiments, the bidding is a semi-open process,allowing the participating suppliers to view the lowest-priced bid orother top bid at any particular point during the bidding process. Insome such embodiments, the top bid is displayed with informationidentifying the supplier that submitted the bid; in other embodiments,the top bid is displayed without identifying information. In still otherembodiments, the bidding is closed such that suppliers cannot view thebids of their competitors. In some such embodiments, the bidding is notiterative. At block 808, the healthcare needs fulfillment system directsprescriptions for particular a particular good or service to therespective preferred supplier for the duration of the next pricingcycle. In some embodiments, the system directs new prescriptionsreceived during the next pricing cycle to the respective preferredsupplier. In some such embodiments, each prescription remains with itsassigned supplier and continues to be filled according to the terms ofthe supplier's bid submission until the prescription expires, forexample, for an entire year or for the lifetime of the prescription.

In some embodiments, participating suppliers may choose which healthcaregoods and services they submit bids for. In some such embodiments, theremay be healthcare goods or services that do not receive any bids.Additionally, in various embodiments, the bidding process may result ina tie for the top bid. In embodiments in which there is no singlepreferred supplier or bid winner, one of a plurality of processes may beimplemented to assign new prescriptions to a supplier for fulfillment.In some embodiments, patient-specific bundling occurs wherein theprescription is transmitted to a certified supplier that has beenselected through the bidding process to fill one or more additionalprescriptions for the patient. In such embodiments, the selectedsupplier is a certified supplier that has submitted the winning bid orbids for one or more additional healthcare goods or services prescribedto the patient. In other embodiments, the prescription is transmitted toa certified supplier identified as having an expertise in a healthcondition associated with the prescribed healthcare good or service. Inother embodiments, the prescription may be transmitted to a certifiedsupplier randomly. In other embodiments, prescriptions for healthcaregoods and services having no winning bidder may be sequentially assignedto a rotation of certified suppliers. In other embodiments, the systemmay bundle a plurality of goods or services without winning bidstogether to form bundled packages; the system may then provide a link tothe certified suppliers to bid on the bundled packages. The prescriptionmay then be transmitted to the supplier that submits a winning bid onthe bundled package that includes the prescribed healthcare good orservice.

FIG. 8B is a flowchart illustrating another embodiment of a method foridentifying a preferred supplier of a prescribed good or service througha bidding process. The method 850 of FIG. 8B may be performed by ahealthcare needs fulfillment system independently or in conjunction withthe bidding process depicted in FIG. 8A. The bidding process of FIG. 8Benables suppliers to offer deals for a period of time that is shorterthan the regular pricing cycle. For example, the suppliers may offer“deals of the day” or “deals of the week.” In the embodiment of FIG. 8B,the healthcare needs fulfillment system receives a first off-cycle bidfrom a supplier for one or more medical goods or services, as shown atblock 852. The bid may apply to all formulations, dosages, sizes, andpharmacy benefits plans, or the bid may specify the limitations of thebid. At block 854, the healthcare needs fulfillment system notifiesother suppliers of the first off-cycle bid received. The notice may besent directly to the suppliers, such as for example, by mail, phone,fax, push notification, or email, or the notice may be posted in theweb-based or application interface. In some embodiments, the othersuppliers are provided with a window of time within which they cansubmit counter-bids. At block 856, the healthcare needs fulfillmentsystem compares the first off-cycle bid to any other bids receivedduring the specified period of time. At block 858, the healthcare needsfulfillment system identifies the preferred off-cycle bid. The preferredbid may be selected based on lowest price alone or on a plurality offactors, such as the factors discussed above. For the specifiedoff-cycle period of time, prescriptions will be directed to the supplierthat submitted the preferred bid for a particular good or service, as inblock 860.

FIG. 9 is a flowchart illustrating an embodiment of a method foranswering patients' questions. The method 900 of various embodiments isperformed by a healthcare needs fulfillment system. The method 900 canbe combined with and/or performed in concert with any of the methods forfulfilling and managing prescriptions described above. As shown at block901, the healthcare needs fulfillment system of some embodimentsreceives patient questions through the web-based or applicationinterface or via an email, text message, or a call center. In someembodiments, the operator of the healthcare needs fulfillment system mayhave the capability of answering some questions directly. In suchembodiments, optional block 802 may be performed. At block 802, thesystem determines whether an answer to a patient's question is readilyavailable onsite. If so, it is answered at block 803. If no, or ifoptional block 802 is skipped, the patient's question is triaged and thegeneral topic determined in order to direct the question to the mostapplicable provider of information. In some embodiments, the healthcareneeds fulfillment system determines whether the question: (1) relates toprescription orders or payments, as in block 904, (2) relates to patienthealth topics, as in block 908, or (3) relates to insurance benefits, asin block 912. In some embodiments in which the question is received viaa call center, the determination is made by providing relevant automatedmenu options to the patient and processing the patient's input. Forexample, in one embodiment, a patient is instructed to “select 1 forquestions related to prescription orders or copayments, 2 for questionsrelated to health and wellness, and 3 for questions related to yourinsurance benefits.” Many other prompts and menu options may be used inother embodiments. In other embodiments, the determination may be madeby an operator speaking to the patient. In still other embodiments, thepatient submits the question via a web-based or application interfaceand is required to specify or select the topic to which the questionpertains before submitting the question. In still other embodiments, thepatient submits the question via the web-based or application interfaceand the system automatically parses the question to identify particularwords it is programmed to associate with particular topics.

In FIG. 9, if it is determined that the patient's question relates toprescription orders or copayments, the patient or question is directedto the pharmacy that is filling the prescription, as in block 906. Ifthe patient's question relates to health or wellness, the patient orquestion is directed to a professional services representative, as inblock 910. Such representatives may be pharmacists, nurse practitioners,or other healthcare professional qualified to answer the patient'squestion. If the patient's question relates to insurance benefits, thehealthcare needs fulfillment system directs the patient or question tothe patient's prescription benefits manager, as in block 914. In someembodiments, if the patient's question does not relate to any of thesetopics, or if the patient fails to select one of the topics, the patientor question is directed to a customer services representative; in otherembodiments, the patient is directed back to a main menu or interface(see block 916). At block 918, the healthcare needs fulfillment systemdetermines whether the patient has one or more additional questions. Ifthe patient has additional questions, the process of triaging andanswering the question is repeated; if not, the patient is disconnected(see block 920) or returned to a homepage.

FIG. 10 provides a flowchart illustrating one embodiment of a method forcurating and delivering content to a patient or other related consumeror user, such as the patient's caregiver or physician. In variousembodiments, the method is performed by a server programmed to form ahealthcare needs fulfillment system. The content of such embodiments iscurated based on a patient's acquisition of a healthcare product orservice, linking the acquisition event to a health condition. In variousembodiments, the system then identifies and delivers to a patient orother user electronic health content relevant to a health state of thepatient. The content may include, for example, articles and otherwritten content and/or interactive web-based or mobile applications.

For example, as shown at block 1002 of FIG. 10, in some embodiments, acomputer, such as a server managed by a plan manager, electronicallyreceives a prescription identifying a prescribed treatment for apatient. The prescribed treatment may be any healthcare good or service.At block 1004, the computer identifies a health condition or a categoryof health conditions the patient is likely to have based on theprescribed treatment for the patient. For example, in some embodiments,the computer identifies the health condition or category of healthconditions by searching a database to identify a product classificationor service classification to which the prescribed treatment belongs. Theclassification may be from the National Drug Code Directory or othersource, or the classifications may be proprietary and created in-house.The classifications may categorize each treatment according to thehealth condition or conditions it treats.

In some embodiments, as shown at block 1006, the computer alsoidentifies content recommended for patients having the health conditionor the category of health conditions. Content may be recommended, forexample, if it has been identified as helpful for explaining a conditionto a patient or helpful for encouraging disease management, healthpromotion, and/or treatment adherence. As one example, an applicationthat stores blood sugar levels for users to review in an easy-to-usemanner may be recommended to patients with diabetes. An application thatprovides a food log interface, calculates sodium content in food, andrecommends low-sodium recipes may be recommended to patients with highblood pressure. Similarly, an application shown to have positive smokingcessation outcomes may be recommended to patients with high bloodpressure who have indicated within their health profile that they aresmokers. An application shown to encourage exercise may also bedelivered to the patients with diabetes and/or high blood pressure. Insome embodiments, a plan manager or outside vendor finds and recommendsnew applications and tags them as applicable to particular healthconditions. In other embodiments, the computer identifies and classifiesapplications automatically by searching an application store for highlyrated applications that have been tagged by the application's creator orthe application store manager as applying to health and/or particularhealth conditions.

At block 1008, the computer delivers the content to the patient or arelated user. The content may be delivered, for example, via email,text, push message or displayed within a web-based or mobile interface.In some embodiments, the content may be directly embedded within thedelivery message. In other embodiments, a link, such as a hyperlink, isprovided to connect the user to the content.

The healthcare needs fulfillment system of various embodiments describedherein is intended to manage and coordinate the fulfillment ofhealthcare needs for thousands or even millions of patients. The systemis configured to facilitate communications between hundreds, thousands,or millions of patients, pharmacies, providers, and physicians at anygiven time.

Those of skill would further appreciate that the various illustrativelogical blocks, modules, circuits, and algorithm steps described inconnection with the embodiments disclosed herein may be implemented aselectronic hardware, computer software, or combinations of both. Toclearly illustrate this interchangeability of hardware and software,various illustrative components, blocks, modules, circuits, and stepshave been described above generally in terms of their functionality.Whether such functionality is implemented as hardware or softwaredepends upon the particular application and design constraints imposedon the overall system. Skilled artisans may implement the describedfunctionality in varying ways for each particular application, but suchimplementation decisions should not be interpreted as causing adeparture from the scope of the present disclosure.

The various illustrative logical blocks, modules, and circuits describedin connection with the embodiments disclosed herein may be implementedor performed with a general purpose processor, a digital signalprocessor (DSP), an application specific integrated circuit (ASIC), afield programmable gate array (FPGA) or other programmable logic device,discrete gate or transistor logic, discrete hardware components, or anycombination thereof designed to perform the functions described herein.A general purpose processor may be a microprocessor, but in thealternative, the processor may be any conventional processor,controller, microcontroller, or state machine. A processor may also beimplemented as a combination of computing devices, e.g., a combinationof a DSP and a microprocessor, a plurality of microprocessors, one ormore microprocessors in conjunction with a DSP core, or any other suchconfiguration.

In one or more example embodiments, the functions described may beimplemented in hardware, software, or firmware executed on a processor,or any combination thereof. If implemented in software, the functionsmay be stored on or transmitted over as one or more instructions or codeon a computer-readable medium. Computer-readable media includes bothcomputer storage media and communication media including any medium thatfacilitates transfer of a computer program from one place to another. Astorage media may be any available media that can be accessed by acomputer. By way of example, and not limitation, such computer-readablemedia can comprise RAM, ROM, EEPROM, CD-ROM or other optical diskstorage, magnetic disk storage or other magnetic storage devices, or anyother medium that can be used to carry or store desired program code inthe form of instructions or data structures and that can be accessed bya computer. Also, any connection is properly termed a computer-readablemedium. For example, if the software is transmitted from a website,server, or other remote source using a coaxial cable, fiber optic cable,twisted pair, digital subscriber line (DSL), or wireless technologiessuch as infrared, radio, and microwave, then the coaxial cable, fiberoptic cable, twisted pair, DSL, or wireless technologies such asinfrared, radio, and microwave are included in the definition of medium.Disk and disc, as used herein, includes compact disc (CD), laser disc,optical disc, digital versatile disc (DVD), floppy disk and Blu-ray discwhere disks usually reproduce data magnetically, while discs reproducedata optically with lasers. Combinations of the above should also beincluded within the scope of computer-readable media.

With respect to the use of substantially any plural and/or singularterms herein, those having skill in the art can translate from theplural to the singular and/or from the singular to the plural as isappropriate to the context and/or application. The varioussingular/plural permutations may be expressly set forth herein for sakeof clarity.

It will be understood by those within the art that, in general, termsused herein, and especially in the appended claims (e.g., bodies of theappended claims) are generally intended as “open” terms (e.g., the term“including” should be interpreted as “including but not limited to,” theterm “having” should be interpreted as “having at least,” the term“includes” should be interpreted as “includes but is not limited to,”etc.). It will be further understood by those within the art that if aspecific number of an introduced claim recitation is intended, such anintent will be explicitly recited in the claim, and in the absence ofsuch recitation no such intent is present. For example, as an aid tounderstanding, the following appended claims may contain usage of theintroductory phrases “at least one” and “one or more” to introduce claimrecitations. However, the use of such phrases should not be construed toimply that the introduction of a claim recitation by the indefinitearticles “a” or “an” limits any particular claim containing suchintroduced claim recitation to embodiments containing only one suchrecitation, even when the same claim includes both the introductoryphrases “one or more” or “at least one” and indefinite articles such as“a” or “an” (e.g., “a” and/or “an” should typically be interpreted tomean “at least one” or “one or more”); the same holds true for the useof definite articles used to introduce claim recitations. In addition,even if a specific number of an introduced claim recitation isexplicitly recited, those skilled in the art will recognize that suchrecitation should typically be interpreted to mean at least the recitednumber (e.g., the bare recitation of “two recitations,” without othermodifiers, typically means at least two recitations, or two or morerecitations).

Furthermore, in those instances where a convention analogous to “atleast one of A, B, and C, etc.” is used, in general such a constructionis intended in the sense one having skill in the art would understandthe convention (e.g., “a system having at least one of A, B, and C”would include but not be limited to systems that have A alone, B alone,C alone, A and B together, A and C together, B and C together, and/or A,B, and C together, etc.). It will be further understood by those withinthe art that virtually any disjunctive word and/or phrase presenting twoor more alternative terms, whether in the description, claims, ordrawings, should be understood to contemplate the possibilities ofincluding one of the terms, either of the terms, or both terms. Forexample, the phrase “A or B” will be understood to include thepossibilities of “A” or “B” or “A and B.”

While the above description has pointed out novel features of theinvention as applied to various embodiments, the skilled person willunderstand that various omissions, substitutions, and changes in theform and details of the device or process illustrated may be madewithout departing from the scope of the invention. Therefore, the scopeof the invention is defined by the claims that follow rather than by theforegoing description. All variations coming within the meaning andrange of equivalency of the claims are embraced within their scope.

What is claimed is:
 1. A method for fulfilling and managingprescriptions, the method implemented by a specialized prescriptionbenefit manager's computer programmed to concurrently manageprescriptions for a multitude of patients, the method comprising:electronically receiving a plurality of prescriptions for a patient fromone or more users' computers, wherein each of the plurality ofprescriptions identifies the patient and a prescribed treatment;selecting supplier selection criteria to apply to the plurality ofprescriptions; applying the supplier selection criteria to automaticallyselect a plurality of suppliers from a set of certified suppliers,wherein each of the plurality of suppliers is selected to fill one ormore of the plurality of prescriptions; transmitting the plurality ofprescriptions to the respective plurality of suppliers for fulfillment;receiving status updates from each of the plurality of suppliers,wherein the status updates comprise prescription receipt confirmation,fulfillment confirmation, and shipment confirmation; and transmittingthe status updates to a patient's computer in a format through which thestatus updates from all the plurality of suppliers are together viewableby the patient within a single user interface.
 2. The method of claim 1,further comprising adjudicating and authorizing fulfillment of each ofthe plurality of prescriptions, wherein adjudicating and authorizingfulfillment occurs prior to transmitting the plurality of prescriptionsto the respective plurality of suppliers for fulfillment.
 3. The methodof claim 1, further comprising: calculating a copayment price owed bythe patient for each of the plurality of prescriptions; accessingaccount information for a financial account of the patient from adatabase; deducting the copayment price from the financial account; andtransmitting a payment to each of the plurality of suppliers.
 4. Themethod of claim 1, further comprising: identifying the patient from eachof the plurality of prescriptions; searching a database to identify aplan to which the patient belongs; and searching a database to identifythe supplier selection criteria associated with the plan; whereinselecting supplier selection criteria to apply to the plurality ofprescriptions comprises selecting the identified supplier selectioncriteria associated with the plan.
 5. The method of claim 1, whereinapplying the supplier selection criteria comprises evaluating the set ofcertified suppliers and selecting the plurality of suppliers based ontotal price of adjudication, wherein for each of the plurality ofprescriptions, the certified supplier offering the lowest total price isselected.
 6. The method of claim 1, wherein applying the supplierselection criteria comprises evaluating the set of certified suppliersand selecting the plurality of suppliers based on a combination of totalprice of adjudication, performance rating, and ancillary serviceofferings.
 7. The method of claim 1, wherein the set of certifiedsuppliers comprise suppliers that meet a minimum level of servicerequirements and have integrated into a healthcare needs fulfillmentsystem operated by a benefits manager.
 8. The method of claim 1, whereina supplier is a pharmacy, a provider of vitamins and nutritionalsupplements, a provider of durable medical equipment, or a provider ofdisposable medical supplies.
 9. A computing system for fulfilling andmanaging prescriptions, the system comprising: a receiver configured toreceive a plurality of prescriptions for a patient from one or moreusers' computers, wherein each of the plurality of prescriptionsidentifies the patient and a prescribed treatment; a transmitterconfigured to transmit the plurality of prescriptions to a plurality ofsuppliers for fulfillment, wherein each of the plurality of suppliershas been selected from a set of certified suppliers to fill one or moreof the plurality of prescriptions; and a processor configured to performa method comprising: selecting supplier selection criteria; and applyingthe supplier selection criteria to automatically select the plurality ofsuppliers from the set of certified suppliers; wherein the receiver isfurther configured to receive status updates from each of the pluralityof suppliers, the status updates comprising prescription receiptconfirmation, fulfillment confirmation, and shipment confirmation, andwherein the transmitter is further configured to transmit the statusupdates to a patient's computer in a format through which the statusupdates from all the plurality of suppliers are together viewable by thepatient within a single user interface.
 10. The system of claim 9,wherein the receiver is further configured to receive data from the setof certified suppliers on which the set of certified suppliers areevaluated, the data comprising one or more of pricing data and ancillaryservice offerings.
 11. The system of claim 9, wherein the processor isfurther configured to perform a method comprising adjudicating andauthorizing fulfillment of each of the plurality of prescriptions priorto transmission of the plurality of prescriptions to the plurality ofsuppliers for fulfillment.
 12. The system of claim 9, wherein theprocessor is further configured to perform a method comprising:calculating a copayment price owed by the patient for each of theplurality of prescriptions; accessing account information for afinancial account of the patient from a database; and deducting thecopayment price from the financial account; and wherein the transmitteris further configured to transmit a payment to each of the plurality ofsuppliers.
 13. The system of claim 9, wherein the processor is furtherconfigured to perform a method comprising: identifying the patient fromeach of the plurality of prescriptions; searching a database to identifya plan to which the patient belongs; and searching a database toidentify the supplier selection criteria associated with the plan;wherein selecting supplier selection criteria to apply to the pluralityof prescriptions comprises selecting the identified supplier selectioncriteria associated with the plan.
 14. A non-transitory machine-readablestorage medium embodying a set of instructions that, when executed by aprocessor, cause the processor to perform operations for fulfilling andmanaging prescriptions, the operations comprising: electronicallyreceiving a plurality of prescriptions for a patient from one or moreusers' computers, wherein each of the plurality of prescriptionsidentifies the patient and a prescribed treatment; selecting supplierselection criteria to apply to the plurality of prescriptions; applyingthe supplier selection criteria to automatically select a plurality ofsuppliers from a set of certified suppliers, wherein each of theplurality of suppliers is selected to fill one or more of the pluralityof prescriptions; transmitting the plurality of prescriptions to therespective plurality of suppliers for fulfillment; receiving statusupdates from each of the plurality of suppliers, wherein the statusupdates comprise prescription receipt confirmation, fulfillmentconfirmation, and shipment confirmation; and transmitting the statusupdates to a patient's computer in a format through which the statusupdates from all the plurality of suppliers are together viewable by thepatient within a single user interface.
 15. The non-transitorymachine-readable storage medium of claim 14, wherein the operationsfurther comprise adjudicating and authorizing fulfillment of each of theplurality of prescriptions, wherein adjudicating and authorizingfulfillment occurs prior to transmitting the plurality of prescriptionsto the respective plurality of suppliers for fulfillment.
 16. Thenon-transitory machine-readable storage medium of claim 14, wherein theoperations further comprise: calculating a copayment price owed by thepatient for each of the plurality of prescriptions; accessing accountinformation for a financial account of the patient from a database;deducting the copayment price from the financial account; andtransmitting a payment to each of the plurality of suppliers.
 17. Thenon-transitory machine-readable storage medium of claim 14, wherein theoperations further comprise: identifying the patient from each of theplurality of prescriptions; searching a database to identify a plan towhich the patient belongs; and searching a database to identify thesupplier selection criteria associated with the plan; wherein selectingsupplier selection criteria to apply to the plurality of prescriptionscomprises selecting the identified supplier selection criteriaassociated with the plan.